Re: release4.0: OFBIZ-1106 (in or out?)
Posted by David E Jones on Nov 15, 2007; 7:24am
URL: http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185478.html
Shoot, forgot the link:
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
-David
On Nov 15, 2007, at 12:21 AM, David E Jones wrote:
>
> Here is the current release plan that explains everything related to
> this. It is certainly open to change.
>
> The best way to do that is probably to propose variations on the
> current plan and open discussion on them.
>
> Will be interesting however the conversation goes... (as Dan Shields
> mentioned, with some liberty in variation)
>
> -David
>
>
> On Nov 14, 2007, at 9:22 PM, Jonathon -- Improov wrote:
>
>> Ok, I'm just speaking from a business perspective here. Obviously,
>> from developer's perspective, it's good to put that enchancement
>> into release 4.0. I agree that this is not a fix, but an enhancement.
>>
>> First, it's cool to be able to tell clients that a new release
>> (after 4.0) fixes a problem with clear passwords being shown. So,
>> I'm for rolling that enhancement into the next release (say 4.1?).
>> Oh yeah, we do agree that upgrading along the 4.x family should
>> involve zero migration effort, right?
>>
>> That said, it should be obvious that my hope is to have release 4.0
>> stabilized asap, and free up resources to package and roll out the
>> next release. If we're not gonna be fast and rapid about the
>> release timeframe, then getting stuck with 4.0 for a long time (say
>> a year?) and stuck with this problem is not fun.
>>
>> Next, I also agree that we cannot dilute the meaning of "bug", and
>> start throwing in seemingly harmless and super-stable enhancements
>> into the release branches. Take no chances. I do agree that this
>> particular enhancement should be simple and superficial enough to
>> be harmless. But for the sake of audit and organization and
>> management, bug fix and enhancement should be handled as clearly
>> distinct categories.
>>
>> Finally, I'd like to suggest a little trick we often do with such
>> deal-breaker "bugs" (ie, "bugs" for which we say "it's a
>> feature!"). Releases like 4.x (where x > 1) can include such
>> enhancements. Sort of like "hotfixes" for release branch 4.
>>
>> Will that mean maintaining 2 branches (4.0 and 4.1), and having to
>> apply any new patches to all members of the 4.x family? Yes! But...
>> it's not difficult. We need to make sure that all members of the
>> 4.x family are fully compatible with each other, ie enhancements
>> being thrown in are truly harmless and superficial enough that each
>> 4.x member is very largely similar (not fundamentally overhauled).
>> In short, all enhancements thrown into the 4.x family must *not*
>> make it less than super-easy to apply bug fixes uniformly to all
>> members. A bug fix to 4.x must be applicable to 4.y without any
>> transformation.
>>
>> Hope that helps?
>>
>> I'd also like to bring in some marketing and sales perspectives.
>> When we market our clients' products, we need to create buzz or
>> activity. Having very regular and frequent releases along the 4.x
>> family makes it tangibly known that OFBiz is super-active and is
>> improving at breakneck speed.
>>
>> Jonathon
>>
>> David E Jones wrote:
>>> I'd prefer not to dilute the meaning of "bug". A bug is an
>>> existing feature that doesn't work as it was intended when written.
>>> Passwords in plain text would be a security issue, but since the
>>> fix for that issue is most likely a new feature rather than fixing
>>> an existing feature (I haven't looked at the code so I don't know
>>> if there is broken code that should do this, but it doesn't sound
>>> like it), then it is a new feature and not a bug.
>>> So, the question that started this thread is the most relevant:
>>> because it is a big concern, should we add this to the branch even
>>> though it is a new feature and not a bug fix?
>>> My opinion on that is let the users of the branch decide... I'm
>>> not really in a good position to express an opinion because I make
>>> a regular practice of pushing clients away from the branch and to
>>> the trunk so that new work we do for them (new stuff being most of
>>> what we do as a company) can be done in participation with the
>>> project.
>>> We could do a formal vote where only PMC votes are binding, but it
>>> might be more valuable to just get feedback from branch users and
>>> make a decision. Purely an administrative comment that.
>>> -David
>>> On Nov 14, 2007, at 11:22 AM, Michael Jensen wrote:
>>>> I agree with Tim. It's a security related bug fix. Displaying
>>>> passwords in plaintext on a screen is a bug. It is industry
>>>> standard
>>>> practice to not show passwords on the screen (either by replacing
>>>> w/asterisks or not displaying characters at all.)
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>> Adrian Crum wrote:
>>>>> Tim,
>>>>>
>>>>> From my perspective, it would be like finding a security breach
>>>>> in the
>>>>> branch. Would we want to close the security breach? Of course!
>>>>> Are we
>>>>> adding a new feature by doing so? I guess some people would
>>>>> consider a
>>>>> closed security breach a "new feature" - but the people
>>>>> downloading and
>>>>> deploying the branch would consider it a bug fix.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Tim Ruppert wrote:
>>>>>
>>>>>> I'm only against breaking the rules of the branch for this one
>>>>>> feature enhancement. If the application doesn't work, then
>>>>>> it's a
>>>>>> fix though. So, I guess it goes back to whether or not this
>>>>>> is a fix
>>>>>> of a problem that was there or is it a feature enhancement?
>>>>>>
>>>>>> Cheers,
>>>>>> Tim
>>>>>> --
>>>>>> Tim Ruppert
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> o:801.649.6594
>>>>>> f:801.649.6595
>>>>>>
>>>>>>
>>>>>> On Nov 14, 2007, at 10:59 AM, Scott Gray wrote:
>>>>>>
>>>>>>> I'm not agiainst it, +1
>>>>>>>
>>>>>>> Scott
>>>>>>>
>>>>>>> On 15/11/2007, Vince M. Clark <[hidden email]> wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Vince Clark
>>>>>>>> Global Era
>>>>>>>> The Freedom of Open Source
>>>>>>>> [hidden email]
>>>>>>>> (303) 493-6723
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Adrian Crum" <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700)
>>>>>>>> America/
>>>>>>>> Denver
>>>>>>>> Subject: Re: release4.0: OFBIZ-1106 (in or out?)
>>>>>>>>
>>>>>>>> While technically it is not a bug fix, I believe it should go
>>>>>>>> in
>>>>>>>> anyway - since the release is
>>>>>>>> intended to be widely deployed, and the problem your patch
>>>>>>>> addresses might be a deal breaker for
>>>>>>>> those who are considering deploying the release.
>>>>>>>>
>>>>>>>> +1 for including it.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> Dan Shields wrote:
>>>>>>>>
>>>>>>>>> Thanks Jacques for helping get my patch for OFBIZ-1106 into
>>>>>>>>> OFBiz.
>>>>>>>>>
>>>>>>>>> Hello Devs, recently I participated with other developers
>>>>>>>>> to devise a
>>>>>>>>> fix for OFBIZ-1106. The patch I submitted is now in HEAD but
>>>>>>>>> UNsurprisingly it has been held back from release4.0 because
>>>>>>>>> the
>>>>>>>>> acceptance criteria, I am told, accepts only bug fixes.
>>>>>>>>>
>>>>>>>>> Some would agree that release4.0 was unusable for POS for
>>>>>>>>> the fact
>>>>>>>>> that it echos the manager's and the user's password to the
>>>>>>>>> screen for
>>>>>>>>> all staff and customers to see. I don't know if any other
>>>>>>>>> developer
>>>>>>>>> has tried to train non-computer people to use the POS
>>>>>>>>> application,
>>>>>>>>> but
>>>>>>>>> I have seen the genuine surprise on their faces when they
>>>>>>>>> saw their
>>>>>>>>> own password appear on the screen as they typed. It should be
>>>>>>>>> self-evident that this is undesirable behavior. My patch
>>>>>>>>> merely
>>>>>>>>> replaces the characters on the screen with asterisks; it
>>>>>>>>> does so in a
>>>>>>>>> manner that respects existing APIs employed by the OFBiz POS
>>>>>>>>> application, it is well-tested, cleanly applies to HEAD and
>>>>>>>>> release4.0, and has been tested by other ofbiz developers as
>>>>>>>>> well.
>>>>>>>>>
>>>>>>>>> It seems that there is some uncertainty over whether this is
>>>>>>>>> in
>>>>>>>>> fact a
>>>>>>>>> bug fix or not. I am merely asking for additional support in
>>>>>>>>> deciding:
>>>>>>>>> "For the purposes of release4.0, is my patch for OFBIZ-1106
>>>>>>>>> a bug
>>>>>>>>> fix?"
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Millcreek Systems, Inc.
>>>> P.O. Box 9835
>>>> Salt Lake City, Utah 84109
>>>> Phone: 801.649.4903
>>>> Skype: millcreeksys (http://millcreeksys.com/skype/)
>>
>
URL: http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185478.html
Shoot, forgot the link:
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
-David
On Nov 15, 2007, at 12:21 AM, David E Jones wrote:
>
> Here is the current release plan that explains everything related to
> this. It is certainly open to change.
>
> The best way to do that is probably to propose variations on the
> current plan and open discussion on them.
>
> Will be interesting however the conversation goes... (as Dan Shields
> mentioned, with some liberty in variation)
>
> -David
>
>
> On Nov 14, 2007, at 9:22 PM, Jonathon -- Improov wrote:
>
>> Ok, I'm just speaking from a business perspective here. Obviously,
>> from developer's perspective, it's good to put that enchancement
>> into release 4.0. I agree that this is not a fix, but an enhancement.
>>
>> First, it's cool to be able to tell clients that a new release
>> (after 4.0) fixes a problem with clear passwords being shown. So,
>> I'm for rolling that enhancement into the next release (say 4.1?).
>> Oh yeah, we do agree that upgrading along the 4.x family should
>> involve zero migration effort, right?
>>
>> That said, it should be obvious that my hope is to have release 4.0
>> stabilized asap, and free up resources to package and roll out the
>> next release. If we're not gonna be fast and rapid about the
>> release timeframe, then getting stuck with 4.0 for a long time (say
>> a year?) and stuck with this problem is not fun.
>>
>> Next, I also agree that we cannot dilute the meaning of "bug", and
>> start throwing in seemingly harmless and super-stable enhancements
>> into the release branches. Take no chances. I do agree that this
>> particular enhancement should be simple and superficial enough to
>> be harmless. But for the sake of audit and organization and
>> management, bug fix and enhancement should be handled as clearly
>> distinct categories.
>>
>> Finally, I'd like to suggest a little trick we often do with such
>> deal-breaker "bugs" (ie, "bugs" for which we say "it's a
>> feature!"). Releases like 4.x (where x > 1) can include such
>> enhancements. Sort of like "hotfixes" for release branch 4.
>>
>> Will that mean maintaining 2 branches (4.0 and 4.1), and having to
>> apply any new patches to all members of the 4.x family? Yes! But...
>> it's not difficult. We need to make sure that all members of the
>> 4.x family are fully compatible with each other, ie enhancements
>> being thrown in are truly harmless and superficial enough that each
>> 4.x member is very largely similar (not fundamentally overhauled).
>> In short, all enhancements thrown into the 4.x family must *not*
>> make it less than super-easy to apply bug fixes uniformly to all
>> members. A bug fix to 4.x must be applicable to 4.y without any
>> transformation.
>>
>> Hope that helps?
>>
>> I'd also like to bring in some marketing and sales perspectives.
>> When we market our clients' products, we need to create buzz or
>> activity. Having very regular and frequent releases along the 4.x
>> family makes it tangibly known that OFBiz is super-active and is
>> improving at breakneck speed.
>>
>> Jonathon
>>
>> David E Jones wrote:
>>> I'd prefer not to dilute the meaning of "bug". A bug is an
>>> existing feature that doesn't work as it was intended when written.
>>> Passwords in plain text would be a security issue, but since the
>>> fix for that issue is most likely a new feature rather than fixing
>>> an existing feature (I haven't looked at the code so I don't know
>>> if there is broken code that should do this, but it doesn't sound
>>> like it), then it is a new feature and not a bug.
>>> So, the question that started this thread is the most relevant:
>>> because it is a big concern, should we add this to the branch even
>>> though it is a new feature and not a bug fix?
>>> My opinion on that is let the users of the branch decide... I'm
>>> not really in a good position to express an opinion because I make
>>> a regular practice of pushing clients away from the branch and to
>>> the trunk so that new work we do for them (new stuff being most of
>>> what we do as a company) can be done in participation with the
>>> project.
>>> We could do a formal vote where only PMC votes are binding, but it
>>> might be more valuable to just get feedback from branch users and
>>> make a decision. Purely an administrative comment that.
>>> -David
>>> On Nov 14, 2007, at 11:22 AM, Michael Jensen wrote:
>>>> I agree with Tim. It's a security related bug fix. Displaying
>>>> passwords in plaintext on a screen is a bug. It is industry
>>>> standard
>>>> practice to not show passwords on the screen (either by replacing
>>>> w/asterisks or not displaying characters at all.)
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>> Adrian Crum wrote:
>>>>> Tim,
>>>>>
>>>>> From my perspective, it would be like finding a security breach
>>>>> in the
>>>>> branch. Would we want to close the security breach? Of course!
>>>>> Are we
>>>>> adding a new feature by doing so? I guess some people would
>>>>> consider a
>>>>> closed security breach a "new feature" - but the people
>>>>> downloading and
>>>>> deploying the branch would consider it a bug fix.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Tim Ruppert wrote:
>>>>>
>>>>>> I'm only against breaking the rules of the branch for this one
>>>>>> feature enhancement. If the application doesn't work, then
>>>>>> it's a
>>>>>> fix though. So, I guess it goes back to whether or not this
>>>>>> is a fix
>>>>>> of a problem that was there or is it a feature enhancement?
>>>>>>
>>>>>> Cheers,
>>>>>> Tim
>>>>>> --
>>>>>> Tim Ruppert
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> o:801.649.6594
>>>>>> f:801.649.6595
>>>>>>
>>>>>>
>>>>>> On Nov 14, 2007, at 10:59 AM, Scott Gray wrote:
>>>>>>
>>>>>>> I'm not agiainst it, +1
>>>>>>>
>>>>>>> Scott
>>>>>>>
>>>>>>> On 15/11/2007, Vince M. Clark <[hidden email]> wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Vince Clark
>>>>>>>> Global Era
>>>>>>>> The Freedom of Open Source
>>>>>>>> [hidden email]
>>>>>>>> (303) 493-6723
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Adrian Crum" <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700)
>>>>>>>> America/
>>>>>>>> Denver
>>>>>>>> Subject: Re: release4.0: OFBIZ-1106 (in or out?)
>>>>>>>>
>>>>>>>> While technically it is not a bug fix, I believe it should go
>>>>>>>> in
>>>>>>>> anyway - since the release is
>>>>>>>> intended to be widely deployed, and the problem your patch
>>>>>>>> addresses might be a deal breaker for
>>>>>>>> those who are considering deploying the release.
>>>>>>>>
>>>>>>>> +1 for including it.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> Dan Shields wrote:
>>>>>>>>
>>>>>>>>> Thanks Jacques for helping get my patch for OFBIZ-1106 into
>>>>>>>>> OFBiz.
>>>>>>>>>
>>>>>>>>> Hello Devs, recently I participated with other developers
>>>>>>>>> to devise a
>>>>>>>>> fix for OFBIZ-1106. The patch I submitted is now in HEAD but
>>>>>>>>> UNsurprisingly it has been held back from release4.0 because
>>>>>>>>> the
>>>>>>>>> acceptance criteria, I am told, accepts only bug fixes.
>>>>>>>>>
>>>>>>>>> Some would agree that release4.0 was unusable for POS for
>>>>>>>>> the fact
>>>>>>>>> that it echos the manager's and the user's password to the
>>>>>>>>> screen for
>>>>>>>>> all staff and customers to see. I don't know if any other
>>>>>>>>> developer
>>>>>>>>> has tried to train non-computer people to use the POS
>>>>>>>>> application,
>>>>>>>>> but
>>>>>>>>> I have seen the genuine surprise on their faces when they
>>>>>>>>> saw their
>>>>>>>>> own password appear on the screen as they typed. It should be
>>>>>>>>> self-evident that this is undesirable behavior. My patch
>>>>>>>>> merely
>>>>>>>>> replaces the characters on the screen with asterisks; it
>>>>>>>>> does so in a
>>>>>>>>> manner that respects existing APIs employed by the OFBiz POS
>>>>>>>>> application, it is well-tested, cleanly applies to HEAD and
>>>>>>>>> release4.0, and has been tested by other ofbiz developers as
>>>>>>>>> well.
>>>>>>>>>
>>>>>>>>> It seems that there is some uncertainty over whether this is
>>>>>>>>> in
>>>>>>>>> fact a
>>>>>>>>> bug fix or not. I am merely asking for additional support in
>>>>>>>>> deciding:
>>>>>>>>> "For the purposes of release4.0, is my patch for OFBIZ-1106
>>>>>>>>> a bug
>>>>>>>>> fix?"
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Millcreek Systems, Inc.
>>>> P.O. Box 9835
>>>> Salt Lake City, Utah 84109
>>>> Phone: 801.649.4903
>>>> Skype: millcreeksys (http://millcreeksys.com/skype/)
>>
>
smime.p7s (3K) | Free forum by Nabble | Edit this page |