http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185429.html
> Notably <<Once a release branch stabilizes an initial "stable" release tag
1. Receive fixes for OFBiz 4.0 branch (it's a progressing branch)
2. Stabilize OFBiz 4.0 branch (time to freeze)
3. Fork a new branch called OFBiz 4.0.stable (non-progressing branch)
That's the meaning of "tag" in SVN. In fact, "tag" in CVS is about the same (effected with
It's the same. A "tag" is simply a branch that (by policy and self-discipline) is never updated,
Think of a "tag" as a teeny tiny branch that serves as a "marker", a stub that never grows.
> hole is like fixing a bug. Because it's not a logical bug but a functionnal
> one. But this concept of "functionnal bug" should not be applied/used outside
It's really hard to say which enhancements fix functional bugs classifiable under "security
fixes". As David Jones said, we really shouldn't muddy up the definition of "bug".
Consider this. Suppose the POS password entering outputs asterisks, 1 for each password character
typed. Suppose a new security adivory gets published that advises to output between 1-3 asterisks
Is the original 1-asterisk-for-1-password-character a security hole? Given the (fictitious)
security advisory, yes! However, it really is still a "new security feature", not a bug fix.
Now consider this scenario where a new user-interface advisory pops up saying that password
entering should be shadowed by displaying the actual password on screen. Why? Well, perhaps it's
simply faster for humans to get through the security check and get working. Maybe humans can type
passwords in faster if they see the password displayed on screen? Maybe that'll prevent really
slow typing of passwords, so slow that on-lookers can see the password from the keyboard? Totally
From what I see, there really is this question: Do we stick to easily classifying fixes and
enhancements, or spend the manpower to decide which enhancements are really fixes?
As you said, manpower is the issue (will always be, for community projects like this). If this
enhancement is now classified as a fix, and in future there are less committers or reviewers, then
> Thanks Jonathon,
>
> This is clearly explained, no doubt. Waiting now for opinions because this means more work for commiters and we should be sure we
> want to go for that.
> I guess the main reason we are doing as it's now is explained in
>
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan#ReleasePlan-GeneralReleasePolicies> Notably <<Once a release branch stabilizes an initial "stable" release tag and pre-built package will be issued>>
>
> Always the man power issue, though as I'm not a svn branch expert I may not understand something here (I seems easier to me to put a
> tag on a branch than to have to deal with multi sub-branches) ?
>
> My question remains : patching security holes should be considered as bug fixes ? It seems that for POS users it's yes, but only in
> this case ? Should we not change our release policy about that point ?
> My opininon is yes : we should consider that fixing an *obvious* security hole is like fixing a bug. Because it's not a logical bug
> but a functionnal one. But this concept of "functionnal bug" should not be applied/used outside of security range else we would
> really then open a can of worms !
>
> Jacques
>
>> Well, clearchris has a point. Is there a defined release date for 4.0?
>>
>> It depends on the management's view of OFBiz 4.0. If it is considered alpha, go on ahead and
>> insert any amount of enhancements into it. But if it is considered beta, it would be good to be
>> strict about things, and pop in only bug fixes.
>>
>> The question to ask is whether management intends for OFBiz 4.0 to be frozen or not. Is it
>> released/published already or not? If it is considered already published, I'd really like to see
>> further enhancements in OFBiz 4.1. From a psychological perspective, it's exciting to see OFBiz
>> 4.1, rather than see OFBiz 4.0 improve tremendously "behind-the-scenes" over one long year.
>>
>> Picture what I'd tell my clients: "Boss, I know OFBiz 4.0 was shaky 10 months ago, but the 4.0
>> then is a far cry from the 4.0 now!". It'd be easier saying: "Boss, we now have OFBiz 4.4. Here
>> are the list of improvements over 4.0.".
>>
>> Then some folks may say that OFBiz 4.0 as it is now is unusable, that no one in right mind will
>> use 4.0 given the horrible security issue outstanding. What then? I say, we let 4.0 die. Time to
>> move on! 4.0 was published, management should stick to that decision. Roll out the next version!
>>
>> Now on to technical considerations. SVN branches are "hotlinked", ie branching 4.1 from 4.0 only
>> creates a cheap reference to 4.0, not an entire copy of 4.0. Any changes to 4.1 will then take up
>> further harddisk space, so only deltas above 4.0 are stored on disk. There will still be only
>> *one* copy of the entire 4.0 code.
>>
>> Now we question whether there'll be tons of confusion if we roll out a whole army of the 4.x
>> family. The crucial thing we *must* do is to make sure the 4.x family are fully compatible with
>> one another such that upgrading/downgrading along the family line requires zero migration effort.
>> Also, make sure that any bug fixes can be *uniformly* applied across the whole family. What that
>> also means is any enhancements that are too radical and that may break above requirement cannot be
>> put into the 4.x family.
>>
>> So what's the point of having 4.0 and 4.1? Ease of bug-reporting! A non-techie person can say "I
>> found the bug in 4.0". So he didn't have time to upgrade to 4.1, or maybe 4.1 is an unlucky number
>> for him. Then the response we give him? "Sir, have you gotten the latest updates for 4.0"? He
>> either says "no" and he updates and retest, or he says "yes" and we hunt for the bug in that
>> *specific release version that is 4.0*! Or if we want to, we could say that "4.0 is dead, please
>> use 4.2".
>>
>> In short, here's the plan. OFBiz 4.1 goes into alpha, and takes in all sorts of enhancements as
>> long as they don't break backward-compatibility with 4.0. OFBiz 4.0 continues beta, until such
>> time that it is super-bugfree. We'll have a series of 4.x members, with the earlier ones getting
>> more stable than the later ones (later ones take in risky new enhancements). How will that happen?
>> Anyone finding a bug in the latest 4.x member can also apply the similar bug fix to 4.0 (or 4.y
>> where y < x). The bug fixes cascade down to earlier 4.x members, making them more stable over
>> time, even as the community tests only the newest 4.x member.
>>
>> Throughout the whole 4.x lineage, no extra harddisk space is taken up. SVN makes cheap "copies".
>> Only deltas are stored.
>>
>> Is that clearly explained? Or did I just confuse version control with cake-baking?
>>
>> Jonathon
>>
>> Jacques Le Roux wrote:
>>> Finally, have we an idea about what to do :o)
>>>
>>> Do we need a vote for this ?
>>> Maybe a generalisation for "security" case as features to back port in any case ?
>>> Create release4.0 (and later when they will come) branches as proposed by Jonathon ?
>>>
>>> Jacques
>>>
>>> De : "clearchris" <
[hidden email]>
>>>> I had no idea the can of worms this would open up when I entered the issue.
>>>>
>>>> I come down on the side of wanting this patch in the release branch.
>>>>
>>>> Further, as there is no defined release date for 4.0, I would consider it
>>>> still open for very high-priority issues that are not traditionally defined
>>>> as "bugs". Ofbiz customers, if they are using the release branch in
>>>> production or close to production would probably do well to lag a bit and
>>>> run with an older revision of the release branch. Regressions can always be
>>>> an issue, even with bug "fixes".
>>>>
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: David E Jones [mailto:
[hidden email]]
>>>> Sent: Thursday, November 15, 2007 4:11 PM
>>>> To:
[hidden email]
>>>> Subject: Re: release4.0: OFBIZ-1106 (in or out?)
>>>>
>>>>
>>>> On Nov 15, 2007, at 11:18 AM, Michael Jensen wrote:
>>>>
>>>>> Using that logic, you could say that almost any previous bugs were
>>>>> really "as-implemented" features and no changes should ever be made to
>>>>> the current release branch.
>>>>> If it was found somewhere in ofbiz that sensitive information was
>>>>> submitted over http instead of https, would that be considered a bug?
>>>>> Or would it be discounted as "well, it's a bad choice but that's how
>>>>> it
>>>>> was implemented"?
>>>>>
>>>>> I understand that the difficult thing about this is that the bug/
>>>>> feature
>>>>> line has to be drawn somewhere. (I know where I'd draw it, especially
>>>>> on security related issues.)
>>>> It's really not that tough... As I described in depth in my previous
>>>> post in this thread there is no need to muddy the meaning of "bug".
>>>>
>>>> Maybe the word you are looking for is "issue"?
>>>>
>>>> This isn't a "bug" per-se, but certainly an "issue" and solving that
>>>> issue requires a new feature. That doesn't mean it can't go into the
>>>> release branch, but non-bug-fixes should be carefully considered
>>>> before being added.
>>>>
>>>>> I'm curious to see how things pan out on this. It will tell me how
>>>>> seriously security is taken by the people driving ofbiz.
>>>> This is a common misconception. There are no "people driving ofbiz".
>>>>
>>>> OFBiz is a community-driven project and things happen when a user
>>>> needs something, implements it, and contributes it back to the
>>>> project. Even committers on OFBiz are just users who have a long
>>>> history of contributions and are invited to be committers to
>>>> facilitate further involvement.
>>>>
>>>> Security or not, things will only be fixed if someone cares enough.
>>>> The flip side of that is that if someone doesn't like how something is
>>>> in OFBiz and they don't do anything about it, they have only
>>>> themselves to blame, as uncomfortable and frighteningly empowering as
>>>> that may be. ;)
>>>>
>>>> -David
>>>>
>>>>
>>>>> Ray Barlow wrote:
>>>>>> As you say plenty of good points so rather than repeat lengthy
>>>>>> arguments
>>>>>> for or against I'll keep it simple and just say I don't think it
>>>>>> should
>>>>>> be described as a bug as it was implemented this way. Bad choice
>>>>>> maybe
>>>>>> but it's a feature change.
>>>>>>
>>>>>> Having said that I do think it should be seriously considered for the
>>>>>> release branch because of it's small footprint and improvement on a
>>>>>> very
>>>>>> weak and insecure area.
>>>>>>
>>>>>> Ray
>>>>>>
>>>>>>
>>>>>> Dan Shields wrote:
>>>>>>> Thanks Jacques. Is there any further action by me that might be
>>>>>>> advised? I was wondering because I was considering declaring a
>>>>>>> referendum on the issue on the user list as per David Jones'
>>>>>>> suggestion.
>>>>>>>
>>>>>>> Wow I guess that what we have here is "the absence of this new
>>>>>>> feature
>>>>>>> is a bug".
>>>>>>>
>>>>>>> I must say, the dev-debate that it has inspired has been impressive!
>>>>>>> There are good arguments both for viewing the patch as a bug, as
>>>>>>> well
>>>>>>> as equally good arguments for viewing it as a feature. It really
>>>>>>> surprised me because up until that point in time (when I blindly
>>>>>>> stumbled into this) my view was entirely to think about it as a bug
>>>>>>> only. The author of OFBIZ-1106 never knew the difference between
>>>>>>> 'code that failed to hide the password' and 'the complete absence of
>>>>>>> code that successfully hid the password', he just knew that the
>>>>>>> software did not do 'as it should', and this was exactly my point of
>>>>>>> view in devising a solution as well. It requires a strong
>>>>>>> metaphysical argument to even tell the difference between the points
>>>>>>> of fact that might exist in the software that would reveal the
>>>>>>> actual
>>>>>>> intent of the original design. My feeling is that it was either
>>>>>>> overlooked accidentally, or it was not convenient to declare the XUI
>>>>>>> XPage in a manner that made sense to have both regular input and
>>>>>>> password input in the same node of the tree but at different times
>>>>>>> (this convenience is what I provided in the patch).
>>>>>>>
>>>>>>> As I said above I am willing to take this to the user list and
>>>>>>> invite
>>>>>>> all users who run a release4.0 branch to submit an accept/reject
>>>>>>> vote,
>>>>>>> as I think this feature/bug (or bug/feature) is important enough to
>>>>>>> the success of release4.0 to warrant.
>>>>>>>
>>>>>>> I am happily sitting on the fence and content to let this issue go
>>>>>>> either way. I am finding it fascinating.
>>>>>>>
>>>>>>> Cheers all
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>
>
>