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" <[EMAIL PROTECTED]> > >> 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:[EMAIL PROTECTED] > >> Sent: Thursday, November 15, 2007 4:11 PM > >> To: dev@ofbiz.apache.org > >> 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 > >>>>> > >>>>> > >> > > > > >
