http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185428.html
This is clearly explained, no doubt. Waiting now for opinions because this means more work for commiters and we should be sure we
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
My question remains : patching security holes should be considered as bug fixes ? It seems that for POS users it's yes, but only in
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
> 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
> >>>>>
> >>>>>
> >>
> >
> >
>