release4.0: OFBIZ-1106 (in or out?)

[Tim Ruppert]

Yeah, no doubt Mike - laying it on thick!

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Nov 15, 2007, at 11:33 AM, Jacopo Cappellato wrote:

> Michael Jensen wrote:
>> ...
>> 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.
>
> Wow... this is a huge pressure!   :-)
>
> Jacopo
>
>> Mike

[Michael Jensen-5]

hehe..
That came across much stronger than I intended.

I love the ofbiz project and a single decision like this one will not
sway me to think that security issues aren't taken seriously by those
driving ofbiz.  Many small decisions (if poor ones in _my_ view) would
slowly change _my_ opinion of how decisions are made w/ofbiz.

Mike


Jacopo Cappellato wrote:

> Michael Jensen wrote:
>> ...
>> 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.
>>
>
> Wow... this is a huge pressure!   :-)
>
> Jacopo
>
>> Mike
>>
>>

--
Millcreek Systems, Inc.
P.O. Box 9835
Salt Lake City, Utah 84109
Phone: [phone]
Skype: millcreeksys (http://millcreeksys.com/skype/)

[David E Jones]

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
>>>
>>>

[jonwimp]

Still, I do understand that it's a hassle to have to apply 10s of mini patches every time I deploy
a new 4.0 implementation.

What does everyone think of labeling OFBiz 4.0 "beta", and creating an "alpha" OFBiz 4.1 where we
can dump such critical enhancements? See my previous post in this thread for that thing about "4.x
family".

Jonathon

BJ Freeman wrote:

> Lets remind everyone that there is a patch for the security.
> it is available to anyone that wants to apply it.
> I do this to my Ver 4.0 (not svn) on patches that have been done to the
> trunk.
> You can have access to all patches that are done to both the trunk and
> the branch by subscribing to the Commit ML.
>
> so the security has been addressed.
>
> this is a discussion about applying such patches to a release branch. It
> is applied to the trunk, so if you want to get the latests and greatest
> including possible bugs that the additions may cause.
> you can use the trunk for you purposes.
>
>
> Michael Jensen sent the following on 11/15/2007 10:18 AM:
>> 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.)
>>
>> 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.
>>
>> Mike
>>
>>
>>
>> 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
>>>>
>>>>  
>>
>>
>
>

[Jacques Le Roux]

De : "Jonathon -- Improov" <[hidden email]>
> Still, I do understand that it's a hassle to have to apply 10s of mini patches every time I deploy
> a new 4.0 implementation.

You cant put them in one sole parch, this is not the harder part, collecting them might be

> What does everyone think of labeling OFBiz 4.0 "beta", and creating an "alpha" OFBiz 4.1 where we
> can dump such critical enhancements? See my previous post in this thread for that thing about "4.x
> family".

Mostly man power issue. This does not mean that we should not discuss about it but please keep in mind OFBis project human
ressources reality

Jacques

> Jonathon
>
> BJ Freeman wrote:
> > Lets remind everyone that there is a patch for the security.
> > it is available to anyone that wants to apply it.
> > I do this to my Ver 4.0 (not svn) on patches that have been done to the
> > trunk.
> > You can have access to all patches that are done to both the trunk and
> > the branch by subscribing to the Commit ML.
> >
> > so the security has been addressed.
> >
> > this is a discussion about applying such patches to a release branch. It
> > is applied to the trunk, so if you want to get the latests and greatest
> > including possible bugs that the additions may cause.
> > you can use the trunk for you purposes.
> >
> >
> > Michael Jensen sent the following on 11/15/2007 10:18 AM:
> >> 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.)
> >>
> >> 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.
> >>
> >> Mike
> >>
> >>
> >>
> >> 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
> >>>>
> >>>>
> >>
> >>
> >
> >
>

[Christopher L]

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
>>>
>>>

[Jacques Le Roux]

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
> >>>
> >>>
>
>

[Scott Gray]

I've been playing with pos for the last week and I've also reviewed this
commit and found no problems with it, I'm quite confident it can be applied
to release branch without causing any problems.  Even though this may not be
a bug in the traditional sense, it does plug a big enough security hole to,
in my opinion, go into the branch.

We could ask for opinions on the user list, but really, is anyone who is
using pos going to prefer unmasked passwords?

Regards
Scott

On 17/11/2007, Jacques Le Roux <[hidden email]> 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
> > >>>
> > >>>
> >
> >
>

[jonwimp]

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
>>>>>
>>>>>
>>
>
>

[BJ Freeman]

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.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
>>>>>>
>>>>>>
>>>
>>
>>
>
>
>
>

[Scott Gray]

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
> >>>>>>
> >>>>>>
> >>>
> >>
> >>
> >
> >
> >
> >
>

[jonwimp]

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
certainly has less problems than the trunk, which is good news!

Come end of 2007, I should have gone through all or most (95%?) of the framework in OFBiz 4.0.
I'll start looking at above-the-framework stuff after that.

Jonathon

Scott Gray wrote:

> 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

[Scott Gray]

On 17/11/2007, Jonathon -- Improov <[hidden email]> wrote:
>
> Ok, ok. I feel so manipulated (private joke with Scott). :P


Don't feel too bad, it's part of my role here to encourage contributions :-)

Scott

[Jacques Le Roux]

> 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 <[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
> > >>>>>>
> > >>>>>>
> > >>>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
>

[Jacques Le Roux]

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" <[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
> >>>>>
> >>>>>
> >>
> >
> >
>

[jonwimp]

 > Notably <<Once a release branch stabilizes an initial "stable" release tag
 > and pre-built package will be issued>>

What this means is:

1. Receive fixes for OFBiz 4.0 branch (it's a progressing branch)

2. Stabilize OFBiz 4.0 branch (time to freeze)

3. Fork a new branch called OFBiz 4.0.stable (non-progressing branch)

That's the meaning of "tag" in SVN. In fact, "tag" in CVS is about the same (effected with
"branching"), just that CVS branching is not the same "cheap copies" as in SVN.

 > 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) ?

It's the same. A "tag" is simply a branch that (by policy and self-discipline) is never updated,
never changed.

A "branch" is a branch that continues to grow.

Think of a "tag" as a teeny tiny branch that serves as a "marker", a stub that never grows.

 > 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 !

It's really hard to say which enhancements fix functional bugs classifiable under "security
fixes". As David Jones said, we really shouldn't muddy up the definition of "bug".

Consider this. Suppose the POS password entering outputs asterisks, 1 for each password character
typed. Suppose a new security adivory gets published that advises to output between 1-3 asterisks
for each password character typed, choosing between 1-3 randomly.

Is the original 1-asterisk-for-1-password-character a security hole? Given the (fictitious)
security advisory, yes! However, it really is still a "new security feature", not a bug fix.

Now consider this scenario where a new user-interface advisory pops up saying that password
entering should be shadowed by displaying the actual password on screen. Why? Well, perhaps it's
simply faster for humans to get through the security check and get working. Maybe humans can type
passwords in faster if they see the password displayed on screen? Maybe that'll prevent really
slow typing of passwords, so slow that on-lookers can see the password from the keyboard? Totally
fictitious, yes, but the point is that a feature is still a feature.

 From what I see, there really is this question: Do we stick to easily classifying fixes and
enhancements, or spend the manpower to decide which enhancements are really fixes?

As you said, manpower is the issue (will always be, for community projects like this). If this
enhancement is now classified as a fix, and in future there are less committers or reviewers, then
who is gonna spend the time to classify future enhancements as fixes?

Jonathon

Jacques Le Roux wrote:

> 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" <[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
>>>>>>>
>>>>>>>
>>>
>
>

[Jacques Le Roux]

Jonathon,

I just re-read you message below and I'm not quite sure to understand because for me a tag is just a name for a revision number.

I wrote
> > Notably <<Once a release branch stabilizes an initial "stable" release tag
>  > and pre-built package will be issued>>

You answered
> What this means is:
>
> 1. Receive fixes for OFBiz 4.0 branch (it's a progressing branch)
ok

> 2. Stabilize OFBiz 4.0 branch (time to freeze)
ok

> 3. Fork a new branch called OFBiz 4.0.stable (non-progressing branch)
ok
>
> That's the meaning of "tag" in SVN. In fact, "tag" in CVS is about the same (effected with
> "branching"), just that CVS branching is not the same "cheap copies" as in SVN.
Do you mean that a tag is also a lazy copie like branches are ?

>
>  > 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) ?
>
> It's the same. A "tag" is simply a branch that (by policy and self-discipline) is never updated,
> never changed.
For me this is 2 differents things. A tag is a named revision number (in trunk or branches), a branch is a copy made at some point
from the trunk (initially) or another branch (thereafter)
> A "branch" is a branch that continues to grow.
>
> Think of a "tag" as a teeny tiny branch that serves as a "marker", a stub that never grows.
Then maybe it's only a vocabulary issue between us. You use tag for a frozen branch, which indeed makes sense in a way.

BTW I think the time is coming to answer questions like in
http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide?focusedCommentId=2604#comment-2604

What to you think, you developpers ?

Jacques

[jonwimp]

 > Do you mean that a tag is also a lazy copie like branches are ?

Yup. Under the hood in SVN, it's exactly like a branch. As I said, a "tag" in SVN is really a
"branch" that is frozen. It is frozen by policy or by self-discipline (human endeavor).

In fact, think of it this way, may be easier. A branch is created with the following steps:

1. A "tag" or "branch stub" is created via a "cheap copy" (or lazy copy?)

2. The "branch stub" is changed, updated, and becomes a "branch" (more than a
    stub).

 > BTW I think the time is coming to answer questions like in
 > http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide?focusedCommentId=2604#comment-2604
 >
 > What to you think, you developpers ?

You mean "how soon will the release be official"?

Right now, if I can help it.

You see, the moment you label a release branch as "beta", it is deemed decent enough to be
published. And "published" in this context will mean publishing a convenient tarball (lessen load
on SVN server). This tarball should be downloaded by very many evaluators and testers (or we can
offer free ice-cream all around the world to recruit more testers). This publication should be
OFBiz 4.0 beta-1.

What about new bugs after OFBiz 4.0 beta-1 is published? Do we say "oops" and "un-publish" the
beta? Nope. Let the testers report the bugs. Keep patching the beta until it's time for the next
release (say... monthly?). When it's time for the next release, release OFBiz 4.0 beta-2.

Replace beta-1 with beta-rc1 if you choose to use the concept of "release candidate".

The way we are doing it now, it's anal-retentive. It's like saying "wait, boss, one more bugfix,
just one more", and saying that for a whole long year! I usually publish "release candidates" for
my boss, let him test it, let him scream the bug reports to me, then release the next "release
candidate" when he's gotten upset enough.

Ok, next question. So why not just let the whole world test the moving OFBiz 4.0 branch? Why
bother with publishing tarballs and release candidates? Here's a simple analogy. Try telling our
bosses "boss, can you learn some SVN and test my bugfixes, so I don't have to prepare tarballs for
you?". Perhaps a good 99% of the population don't want to hear the 3 letters "SVN" when they
attempt to download and test OFBiz.

Also, given that the 3rd-party binaries (more than 50% of OFBiz download size is *not* OFBiz
codes!) is in the SVN, it is in the OFBiz PMC's interest to lessen the load on the SVN server
wherever possible.

Just my 2 cents. I'm feeling very embarrassed for beating this topic so much to death by now.

Jonathon

Jacques Le Roux wrote:

> Jonathon,
>
> I just re-read you message below and I'm not quite sure to understand because for me a tag is just a name for a revision number.
>
> I wrote
>>> Notably <<Once a release branch stabilizes an initial "stable" release tag
>>  > and pre-built package will be issued>>
>
> You answered
>> What this means is:
>>
>> 1. Receive fixes for OFBiz 4.0 branch (it's a progressing branch)
> ok
>
>> 2. Stabilize OFBiz 4.0 branch (time to freeze)
> ok
>
>> 3. Fork a new branch called OFBiz 4.0.stable (non-progressing branch)
> ok
>> That's the meaning of "tag" in SVN. In fact, "tag" in CVS is about the same (effected with
>> "branching"), just that CVS branching is not the same "cheap copies" as in SVN.
> Do you mean that a tag is also a lazy copie like branches are ?
>
>>  > 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) ?
>>
>> It's the same. A "tag" is simply a branch that (by policy and self-discipline) is never updated,
>> never changed.
> For me this is 2 differents things. A tag is a named revision number (in trunk or branches), a branch is a copy made at some point
> from the trunk (initially) or another branch (thereafter)
>> A "branch" is a branch that continues to grow.
>>
>> Think of a "tag" as a teeny tiny branch that serves as a "marker", a stub that never grows.
> Then maybe it's only a vocabulary issue between us. You use tag for a frozen branch, which indeed makes sense in a way.
>
> BTW I think the time is coming to answer questions like in
> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide?focusedCommentId=2604#comment-2604
>
> What to you think, you developpers ?
>
> Jacques
>
>

[David E Jones]

On Nov 26, 2007, at 10:32 AM, Jonathon -- Improov wrote:

> The way we are doing it now, it's anal-retentive. It's like saying  
> "wait, boss, one more bugfix, just one more", and saying that for a  
> whole long year! I usually publish "release candidates" for my boss,  
> let him test it, let him scream the bug reports to me, then release  
> the next "release candidate" when he's gotten upset enough.

Maybe the way you are doing it now... "we" is going a little far...

> Ok, next question. So why not just let the whole world test the  
> moving OFBiz 4.0 branch? Why bother with publishing tarballs and  
> release candidates? Here's a simple analogy. Try telling our bosses  
> "boss, can you learn some SVN and test my bugfixes, so I don't have  
> to prepare tarballs for you?". Perhaps a good 99% of the population  
> don't want to hear the 3 letters "SVN" when they attempt to download  
> and test OFBiz.

There is certainly a target audience in that. But consider the nature  
of OFBiz: it is most commonly used by developers or analysts that full-
on customize or at least significantly configure OFBiz to make it  
possible to use in their businesses. It just isn't designed and hasn't  
been implemented for OOTB (out-of-the-box) use.

Also consider that what we really need for a strong community is for  
users to offer feedback and contributions to move the project forward.  
In fact that is the ONLY way that OFBiz moves forward as there is no  
company that owns or sponsors OFBiz.

So, we WANT people to use OFBiz from SVN. I don't know about the  
others who are involved more actively in managing and moderating OFBiz  
(ie the PMC members and committers), but for me the thought of having  
thousands of users who don't want to customize and don't contribute is  
REALLY scary. Imagine all of the complaints and problems that the  
current community isn't big or experienced enough to support for free  
in a good old community fashion...

Don't get me wrong, I ONLY wrote what and I wrote and don't read other  
stuff into it. This (a binary release) IS something that is necessary  
to help grow the project, but with limited resources and most of those  
going into trying to stabilize development and contributions because  
most contributors write WAY more than they read and research... we are  
where we are, and it is what it is. To put it in more concrete terms:  
if I have to spend 20 hours a week researching stuff so people don't  
commit things that are inconsistent or difficult to manage or  
contradict or break things that exist, where do I get time to actually  
do administrative tasks like creating a binary release?

> Also, given that the 3rd-party binaries (more than 50% of OFBiz  
> download size is *not* OFBiz codes!) is in the SVN, it is in the  
> OFBiz PMC's interest to lessen the load on the SVN server wherever  
> possible.

Nice try. Machines are machines and are cheap and easy to manage.  
People are people and are expensive and difficult to manage. It's that  
simple. If it makes things more difficult for developers it will  
hamper or kill the project.

Not gonna happen, especially if we want it to be possible to have  
enough resources to put together a binary release anytime soon...

> Just my 2 cents. I'm feeling very embarrassed for beating this topic  
> so much to death by now.

Your comments are always welcome. Feel free to re-hash too, things  
certainly change over time. Just don't be too surprised if I pull out  
every gun I can think of to argue against something that I think will  
be bad for the project, especially if I am re-writing the thoughts.

-David

[David E Jones]

On Nov 26, 2007, at 9:19 AM, Jacques Le Roux wrote:

> BTW I think the time is coming to answer questions like in
> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide?focusedCommentId=2604#comment-2604
>
> What to you think, you developpers ?

I think first things first...

The first question for the release4.0 branch is: is it ready from a  
code, etc perspective to be released?

I asked a question a few weeks ago to try to determine how many people  
are using the release branch and have found it sufficient for even a  
"beta" label (which technically even the trunk SHOULD have, ie no one  
should commit anything that isn't at least point tested)?

It only takes a couple of hours to build the release and get it  
uploaded and such. I pretty much have to do that as I'm the one who  
has been signing the releases and such (it is my signature in the KEYS  
file, etc).

Before that happens we need to make sure we're ready for a release as  
a community, and then the PMC needs to vote on a candidate revision in  
the branch for a binary release.

Right now I personally haven't tested it much, and I realistically  
won't be able to, but I am willing to vote for it if there is enough  
community feedback that it is in a good state for release. In fact,  
I'd be ecstatic to see this happen! Each PMC member needs to consider  
their own criteria for the binary release being ready, and right now  
this is mine.

So, that gets us back to the first things first thingy mentioned  
above...

Please comment everyone so we can get this moving forward!

I'll leave this on the dev list for now and we can start something in  
a bit on the user list if there isn't enough feedback here.

-David