http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185458.html
Ok, ok. I feel so manipulated (private joke with Scott). :P
I am using OFBiz 4.0 extensively. But haven't found a lot of problems worth mentioning. It
Come end of 2007, I should have gone through all or most (95%?) of the framework in OFBiz 4.0.
> 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.
>
> Regards
> Scott
>
> On 17/11/2007, BJ Freeman <
[hidden email]> 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" <
[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
>>>>>>>>
>>>>>>>>
>>>>
>>>
>>>
>>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.16.0/1135 - Release Date: 11/16/2007 10:58 PM