> Exactly right BJ, for releases to move faster the community needs to move > faster. The committers have put a lot more time into contributing to the > release (mostly via back patching) than the rest of the community and IMO > that is the reverse of how it should be. No matter what the release plan > ends up looking like, if the community doesn't support the release via > extensive use, testing and bug reports (with fixes!) then it will always > move more like the tortoise than the hare.
Applauses ! Jacques PS : begin to wonder if we have really an users community or only lurkers picking things when they need them, certainly paranoïd... > > Regards > Scott > > On 17/11/2007, BJ Freeman <[EMAIL PROTECTED]> wrote: > > > > about a month ago david ask the community for feed back on those that > > have 4.0 in production. > > I have not see that much feed back about it so apparently there are not > > that many using it in production. > > I believe once more report that they are using 4.0 in production and are > > not running into problems that would the be point to freeze it and > > release. > > > > > > > > Jonathon -- Improov sent the following on 11/16/2007 7:18 PM: > > > 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.xmember. > > > > > > 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 > > >>>>>> > > >>>>>> > > >>> > > >> > > >> > > > > > > > > > > > > > > >
