You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2007/06/14 22:51:32 UTC
Workeffort Bug vs New Feature
Moving this to a new thread. I apologize for the threadjack Scott.
I'm puzzled. A Workeffort screen displays a calendar incorrectly and I submit a patch that fixes it.
How is that a new feature?
It sounds to me like bug fixes are okay as long as they don't introduce new code. What if fixing a
bug requires new code?
On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>
> Then I guess it depends on whether or not the rest of the fix is indeed
> fixing a bug or new features :)
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>
> From my perspective, having two 4ths and only 29 days in November is a
> bug.
>
> David E Jones wrote:
>
> I don't know... that's a fairly big change and in a very real way
> supporting DST changes is a new feature...
> That's my opinion anyway. Doesn't this also depend on a fair amount of
> other new functionality?
> -David
> Adrian Crum wrote:
>
> Scott,
>
> This isn't already committed, but it needs to go into both -
>
> https://issues.apache.org/jira/browse/OFBIZ-1069
>
> -Adrian
>
> Scott Gray wrote:
>
> Hi All,
>
> I'll be reviewing the last fortnight's trunk commits for merging back to
> the
> release branch tonight, so if anyone knows of any trunk commits that
> should
> be merged it would be great if you could post them here.
>
> Thanks
> Scott
>
>
>
>
Re: Workeffort Bug vs New Feature
Posted by Jonathon -- Improov <jo...@improov.com>.
This is one of those bugfixes that are non-trivial (involving new components and supporting
codes?). It should take as much work to put into OFBiz 4.0 branch as it did to commit it to trunk.
Unless...
Unless it is one of those bugs that are not _exactly_ present in the OFBiz 4.0 branch. If it is
one of these, someone will need to do some human intervention and reading of both branches to
"massage" the bugfix into OFBiz 4.0 branch. I doubt it is a bug or bugfix of this sort?
Granted, the required new components and supporting codes may themselves introduce destabilizing
bugs into 4.0 branch. If this is the case, the next best thing, really, is simply to: Fix the
29-day bug in OFBiz 4.0 branch _with_ the branch's own components and supporting codes, and _not_
pull in the bugfix (nor the supporting codes) from trunk at all. In this case, I think the trunk's
bugfix can easily educate us on how to "recreate" the bugfix in the 4.0 branch. (I vote for this
approach.)
Hope that clears things up more than muddle stuff up. I'm one of the guilty ones who pushed for a
stabilizing branch release, kicking and screaming about it.
Jonathon
Ean Schuessler wrote:
> On Thursday 14 June 2007 04:14:18 pm Adrian Crum wrote:
>> In other words, it's okay for the system to function incorrectly, as long
>> as it consistently functions incorrectly.
>>
>> ;)
>>
>> If you prefer to keep the Workeffort calendar broken, that's fine with me.
>> When new users ask why release version 4 has only 29 days in November, I
>> can point them to this discussion and let them know that November 30th was
>> a new feature that didn't make it into the release.
>
> Ha! Ha ha! Well played.
>
> I haven't read this patch but it seems like this bug makes us look rather
> foolish. I'd vote +1 for that going in even though we are in a freeze, if I
> was the voting type.
>
> Seems like the screen already exists so this isn't "new" even if the
> implementation is moves around a little. Any new bugs would have to do be
> pretty significant to compete with a 29 day November.
>
Re: Workeffort Bug vs New Feature
Posted by Ean Schuessler <ea...@brainfood.com>.
On Thursday 14 June 2007 04:14:18 pm Adrian Crum wrote:
> In other words, it's okay for the system to function incorrectly, as long
> as it consistently functions incorrectly.
>
> ;)
>
> If you prefer to keep the Workeffort calendar broken, that's fine with me.
> When new users ask why release version 4 has only 29 days in November, I
> can point them to this discussion and let them know that November 30th was
> a new feature that didn't make it into the release.
Ha! Ha ha! Well played.
I haven't read this patch but it seems like this bug makes us look rather
foolish. I'd vote +1 for that going in even though we are in a freeze, if I
was the voting type.
Seems like the screen already exists so this isn't "new" even if the
implementation is moves around a little. Any new bugs would have to do be
pretty significant to compete with a 29 day November.
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Workeffort Bug vs New Feature
Posted by Jacopo Cappellato <ti...@sastau.it>.
Adrian,
yes, I really mentioned OFBIZ-1079 because the id is very similar to
OFBIZ-1069, and on the same area... so it could have caused some confusion.
Jacopo
Adrian Crum wrote:
> Jacopo,
>
> You are absolutely right. OFBIZ-1079 is still a work in progress and
> that is clearly a new feature - no argument there.
>
> Just to make sure there is no misunderstanding on the list, I'm only
> referring to OFBIZ-1069 - not any of the other improvements I've
> mentioned in the past.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>
>> Adrian,
>>
>> in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079 should not.
>> However I really think that it is very important to maintain a
>> relaxed, positive and constructive attitude between us especially when
>> we disagree or have different opinion.
>>
>> Jacopo
>>
>>
>> Adrian Crum wrote:
>>
>>> David E Jones wrote:
>>>
>>>>
>>>> The primary goal of a release branch is to stabilize current
>>>> functionality.
>>>>
>>>> Generally a very important part of that is to not introduce new
>>>> functionality that might cause new bugs. That doesn't mean
>>>> everything one might want or that might be implied in the data model
>>>> or other parts of the system will work as expected, it just means
>>>> that everything that IS implemented will function.
>>>>
>>>> Some things are difficult to decide on, but remember the first
>>>> priority is stabilization.
>>>>
>>>> -David
>>>
>>>
>>> In other words, it's okay for the system to function incorrectly, as
>>> long as it consistently functions incorrectly.
>>>
>>> ;)
>>>
>>> If you prefer to keep the Workeffort calendar broken, that's fine
>>> with me. When new users ask why release version 4 has only 29 days in
>>> November, I can point them to this discussion and let them know that
>>> November 30th was a new feature that didn't make it into the release.
>>>
>>>>
>>>>
>>>> Adrian Crum wrote:
>>>>
>>>>> Moving this to a new thread. I apologize for the threadjack Scott.
>>>>>
>>>>> I'm puzzled. A Workeffort screen displays a calendar incorrectly
>>>>> and I submit a patch that fixes it. How is that a new feature?
>>>>>
>>>>> It sounds to me like bug fixes are okay as long as they don't
>>>>> introduce new code. What if fixing a bug requires new code?
>>>>>
>>>>>
>>>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>>
>>>>> >
>>>>> > Then I guess it depends on whether or not the rest of the fix is
>>>>> indeed
>>>>> > fixing a bug or new features :)
>>>>> >
>>>>> > Cheers,
>>>>> > Tim
>>>>> > --
>>>>> > Tim Ruppert
>>>>> > HotWax Media
>>>>> > http://www.hotwaxmedia.com
>>>>> >
>>>>> > o:801.649.6594
>>>>> > f:801.649.6595
>>>>> >
>>>>> >
>>>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>>>>> >
>>>>> > From my perspective, having two 4ths and only 29 days in
>>>>> November is a
>>>>> > bug.
>>>>> >
>>>>> > David E Jones wrote:
>>>>> >
>>>>> > I don't know... that's a fairly big change and in a very real way
>>>>> > supporting DST changes is a new feature...
>>>>> > That's my opinion anyway. Doesn't this also depend on a fair
>>>>> amount of
>>>>> > other new functionality?
>>>>> > -David
>>>>> > Adrian Crum wrote:
>>>>> >
>>>>> > Scott,
>>>>> >
>>>>> > This isn't already committed, but it needs to go into both -
>>>>> >
>>>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>>>>> >
>>>>> > -Adrian
>>>>> >
>>>>> > Scott Gray wrote:
>>>>> >
>>>>> > Hi All,
>>>>> >
>>>>> > I'll be reviewing the last fortnight's trunk commits for merging
>>>>> back to
>>>>> > the
>>>>> > release branch tonight, so if anyone knows of any trunk commits
>>>>> that
>>>>> > should
>>>>> > be merged it would be great if you could post them here.
>>>>> >
>>>>> > Thanks
>>>>> > Scott
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>
>>
Re: Workeffort Bug vs New Feature
Posted by Scott Gray <le...@gmail.com>.
I don't have a problem with this going into 4.0
Regards
Scott
On 15/06/07, Adrian Crum <ad...@hlmksw.com> wrote:
>
> Jacopo,
>
> You are absolutely right. OFBIZ-1079 is still a work in progress and that
> is clearly a new feature -
> no argument there.
>
> Just to make sure there is no misunderstanding on the list, I'm only
> referring to OFBIZ-1069 - not
> any of the other improvements I've mentioned in the past.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>
> > Adrian,
> >
> > in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079 should not.
> > However I really think that it is very important to maintain a relaxed,
> > positive and constructive attitude between us especially when we
> > disagree or have different opinion.
> >
> > Jacopo
> >
> >
> > Adrian Crum wrote:
> >
> >> David E Jones wrote:
> >>
> >>>
> >>> The primary goal of a release branch is to stabilize current
> >>> functionality.
> >>>
> >>> Generally a very important part of that is to not introduce new
> >>> functionality that might cause new bugs. That doesn't mean everything
> >>> one might want or that might be implied in the data model or other
> >>> parts of the system will work as expected, it just means that
> >>> everything that IS implemented will function.
> >>>
> >>> Some things are difficult to decide on, but remember the first
> >>> priority is stabilization.
> >>>
> >>> -David
> >>
> >>
> >> In other words, it's okay for the system to function incorrectly, as
> >> long as it consistently functions incorrectly.
> >>
> >> ;)
> >>
> >> If you prefer to keep the Workeffort calendar broken, that's fine with
> >> me. When new users ask why release version 4 has only 29 days in
> >> November, I can point them to this discussion and let them know that
> >> November 30th was a new feature that didn't make it into the release.
> >>
> >>>
> >>>
> >>> Adrian Crum wrote:
> >>>
> >>>> Moving this to a new thread. I apologize for the threadjack Scott.
> >>>>
> >>>> I'm puzzled. A Workeffort screen displays a calendar incorrectly and
> >>>> I submit a patch that fixes it. How is that a new feature?
> >>>>
> >>>> It sounds to me like bug fixes are okay as long as they don't
> >>>> introduce new code. What if fixing a bug requires new code?
> >>>>
> >>>>
> >>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> >>>>
> >>>> >
> >>>> > Then I guess it depends on whether or not the rest of the fix is
> >>>> indeed
> >>>> > fixing a bug or new features :)
> >>>> >
> >>>> > Cheers,
> >>>> > Tim
> >>>> > --
> >>>> > Tim Ruppert
> >>>> > HotWax Media
> >>>> > http://www.hotwaxmedia.com
> >>>> >
> >>>> > o:801.649.6594
> >>>> > f:801.649.6595
> >>>> >
> >>>> >
> >>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
> >>>> >
> >>>> > From my perspective, having two 4ths and only 29 days in November
> >>>> is a
> >>>> > bug.
> >>>> >
> >>>> > David E Jones wrote:
> >>>> >
> >>>> > I don't know... that's a fairly big change and in a very real way
> >>>> > supporting DST changes is a new feature...
> >>>> > That's my opinion anyway. Doesn't this also depend on a fair
> >>>> amount of
> >>>> > other new functionality?
> >>>> > -David
> >>>> > Adrian Crum wrote:
> >>>> >
> >>>> > Scott,
> >>>> >
> >>>> > This isn't already committed, but it needs to go into both -
> >>>> >
> >>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
> >>>> >
> >>>> > -Adrian
> >>>> >
> >>>> > Scott Gray wrote:
> >>>> >
> >>>> > Hi All,
> >>>> >
> >>>> > I'll be reviewing the last fortnight's trunk commits for merging
> >>>> back to
> >>>> > the
> >>>> > release branch tonight, so if anyone knows of any trunk commits
> that
> >>>> > should
> >>>> > be merged it would be great if you could post them here.
> >>>> >
> >>>> > Thanks
> >>>> > Scott
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>>
> >
> >
>
Re: Workeffort Bug vs New Feature
Posted by Adrian Crum <ad...@hlmksw.com>.
Jacopo,
You are absolutely right. OFBIZ-1079 is still a work in progress and that is clearly a new feature -
no argument there.
Just to make sure there is no misunderstanding on the list, I'm only referring to OFBIZ-1069 - not
any of the other improvements I've mentioned in the past.
-Adrian
Jacopo Cappellato wrote:
> Adrian,
>
> in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079 should not.
> However I really think that it is very important to maintain a relaxed,
> positive and constructive attitude between us especially when we
> disagree or have different opinion.
>
> Jacopo
>
>
> Adrian Crum wrote:
>
>> David E Jones wrote:
>>
>>>
>>> The primary goal of a release branch is to stabilize current
>>> functionality.
>>>
>>> Generally a very important part of that is to not introduce new
>>> functionality that might cause new bugs. That doesn't mean everything
>>> one might want or that might be implied in the data model or other
>>> parts of the system will work as expected, it just means that
>>> everything that IS implemented will function.
>>>
>>> Some things are difficult to decide on, but remember the first
>>> priority is stabilization.
>>>
>>> -David
>>
>>
>> In other words, it's okay for the system to function incorrectly, as
>> long as it consistently functions incorrectly.
>>
>> ;)
>>
>> If you prefer to keep the Workeffort calendar broken, that's fine with
>> me. When new users ask why release version 4 has only 29 days in
>> November, I can point them to this discussion and let them know that
>> November 30th was a new feature that didn't make it into the release.
>>
>>>
>>>
>>> Adrian Crum wrote:
>>>
>>>> Moving this to a new thread. I apologize for the threadjack Scott.
>>>>
>>>> I'm puzzled. A Workeffort screen displays a calendar incorrectly and
>>>> I submit a patch that fixes it. How is that a new feature?
>>>>
>>>> It sounds to me like bug fixes are okay as long as they don't
>>>> introduce new code. What if fixing a bug requires new code?
>>>>
>>>>
>>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>
>>>> >
>>>> > Then I guess it depends on whether or not the rest of the fix is
>>>> indeed
>>>> > fixing a bug or new features :)
>>>> >
>>>> > Cheers,
>>>> > Tim
>>>> > --
>>>> > Tim Ruppert
>>>> > HotWax Media
>>>> > http://www.hotwaxmedia.com
>>>> >
>>>> > o:801.649.6594
>>>> > f:801.649.6595
>>>> >
>>>> >
>>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>>>> >
>>>> > From my perspective, having two 4ths and only 29 days in November
>>>> is a
>>>> > bug.
>>>> >
>>>> > David E Jones wrote:
>>>> >
>>>> > I don't know... that's a fairly big change and in a very real way
>>>> > supporting DST changes is a new feature...
>>>> > That's my opinion anyway. Doesn't this also depend on a fair
>>>> amount of
>>>> > other new functionality?
>>>> > -David
>>>> > Adrian Crum wrote:
>>>> >
>>>> > Scott,
>>>> >
>>>> > This isn't already committed, but it needs to go into both -
>>>> >
>>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>>>> >
>>>> > -Adrian
>>>> >
>>>> > Scott Gray wrote:
>>>> >
>>>> > Hi All,
>>>> >
>>>> > I'll be reviewing the last fortnight's trunk commits for merging
>>>> back to
>>>> > the
>>>> > release branch tonight, so if anyone knows of any trunk commits that
>>>> > should
>>>> > be merged it would be great if you could post them here.
>>>> >
>>>> > Thanks
>>>> > Scott
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>
>
Re: Workeffort Bug vs New Feature
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
I'm American, but thank god I've never been referred to as "snarky" :)
+1 on Jacopo's comments about the release.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Jun 14, 2007, at 3:29 PM, Adrian Crum wrote:
> Jacopo,
>
> I'm relaxed and positive. I'm just being what Americans call
> "snarky." Hence the ;)
>
> Here's another one in case anyone missed it
>
> ;)
>
> -Adrian
>
>
> Jacopo Cappellato wrote:
>> Adrian,
>> in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079
>> should not.
>> However I really think that it is very important to maintain a
>> relaxed, positive and constructive attitude between us especially
>> when we disagree or have different opinion.
>> Jacopo
>> Adrian Crum wrote:
>>> David E Jones wrote:
>>>
>>>>
>>>> The primary goal of a release branch is to stabilize current
>>>> functionality.
>>>>
>>>> Generally a very important part of that is to not introduce new
>>>> functionality that might cause new bugs. That doesn't mean
>>>> everything one might want or that might be implied in the data
>>>> model or other parts of the system will work as expected, it
>>>> just means that everything that IS implemented will function.
>>>>
>>>> Some things are difficult to decide on, but remember the first
>>>> priority is stabilization.
>>>>
>>>> -David
>>>
>>>
>>> In other words, it's okay for the system to function incorrectly,
>>> as long as it consistently functions incorrectly.
>>>
>>> ;)
>>>
>>> If you prefer to keep the Workeffort calendar broken, that's fine
>>> with me. When new users ask why release version 4 has only 29
>>> days in November, I can point them to this discussion and let
>>> them know that November 30th was a new feature that didn't make
>>> it into the release.
>>>
>>>>
>>>>
>>>> Adrian Crum wrote:
>>>>
>>>>> Moving this to a new thread. I apologize for the threadjack Scott.
>>>>>
>>>>> I'm puzzled. A Workeffort screen displays a calendar
>>>>> incorrectly and I submit a patch that fixes it. How is that a
>>>>> new feature?
>>>>>
>>>>> It sounds to me like bug fixes are okay as long as they don't
>>>>> introduce new code. What if fixing a bug requires new code?
>>>>>
>>>>>
>>>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>>
>>>>> >
>>>>> > Then I guess it depends on whether or not the rest of the
>>>>> fix is indeed
>>>>> > fixing a bug or new features :)
>>>>> >
>>>>> > Cheers,
>>>>> > Tim
>>>>> > --
>>>>> > Tim Ruppert
>>>>> > HotWax Media
>>>>> > http://www.hotwaxmedia.com
>>>>> >
>>>>> > o:801.649.6594
>>>>> > f:801.649.6595
>>>>> >
>>>>> >
>>>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>>>>> >
>>>>> > From my perspective, having two 4ths and only 29 days in
>>>>> November is a
>>>>> > bug.
>>>>> >
>>>>> > David E Jones wrote:
>>>>> >
>>>>> > I don't know... that's a fairly big change and in a very
>>>>> real way
>>>>> > supporting DST changes is a new feature...
>>>>> > That's my opinion anyway. Doesn't this also depend on a fair
>>>>> amount of
>>>>> > other new functionality?
>>>>> > -David
>>>>> > Adrian Crum wrote:
>>>>> >
>>>>> > Scott,
>>>>> >
>>>>> > This isn't already committed, but it needs to go into both -
>>>>> >
>>>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>>>>> >
>>>>> > -Adrian
>>>>> >
>>>>> > Scott Gray wrote:
>>>>> >
>>>>> > Hi All,
>>>>> >
>>>>> > I'll be reviewing the last fortnight's trunk commits for
>>>>> merging back to
>>>>> > the
>>>>> > release branch tonight, so if anyone knows of any trunk
>>>>> commits that
>>>>> > should
>>>>> > be merged it would be great if you could post them here.
>>>>> >
>>>>> > Thanks
>>>>> > Scott
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
Re: Workeffort Bug vs New Feature
Posted by David E Jones <jo...@hotwaxmedia.com>.
To be clear, I didn't review this thoroughly to see what was working or not and how the problem impacted things.
I didn't say leave it out, I just said be careful about the which side of the line we decide to put things.
If you feel it's an important change, go for it!
-David
Adrian Crum wrote:
> Jacopo,
>
> I'm relaxed and positive. I'm just being what Americans call "snarky."
> Hence the ;)
>
> Here's another one in case anyone missed it
>
> ;)
>
> -Adrian
>
>
> Jacopo Cappellato wrote:
>> Adrian,
>>
>> in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079 should not.
>> However I really think that it is very important to maintain a
>> relaxed, positive and constructive attitude between us especially when
>> we disagree or have different opinion.
>>
>> Jacopo
>>
>>
>> Adrian Crum wrote:
>>
>>> David E Jones wrote:
>>>
>>>>
>>>> The primary goal of a release branch is to stabilize current
>>>> functionality.
>>>>
>>>> Generally a very important part of that is to not introduce new
>>>> functionality that might cause new bugs. That doesn't mean
>>>> everything one might want or that might be implied in the data model
>>>> or other parts of the system will work as expected, it just means
>>>> that everything that IS implemented will function.
>>>>
>>>> Some things are difficult to decide on, but remember the first
>>>> priority is stabilization.
>>>>
>>>> -David
>>>
>>>
>>> In other words, it's okay for the system to function incorrectly, as
>>> long as it consistently functions incorrectly.
>>>
>>> ;)
>>>
>>> If you prefer to keep the Workeffort calendar broken, that's fine
>>> with me. When new users ask why release version 4 has only 29 days in
>>> November, I can point them to this discussion and let them know that
>>> November 30th was a new feature that didn't make it into the release.
>>>
>>>>
>>>>
>>>> Adrian Crum wrote:
>>>>
>>>>> Moving this to a new thread. I apologize for the threadjack Scott.
>>>>>
>>>>> I'm puzzled. A Workeffort screen displays a calendar incorrectly
>>>>> and I submit a patch that fixes it. How is that a new feature?
>>>>>
>>>>> It sounds to me like bug fixes are okay as long as they don't
>>>>> introduce new code. What if fixing a bug requires new code?
>>>>>
>>>>>
>>>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>>
>>>>> >
>>>>> > Then I guess it depends on whether or not the rest of the fix is
>>>>> indeed
>>>>> > fixing a bug or new features :)
>>>>> >
>>>>> > Cheers,
>>>>> > Tim
>>>>> > --
>>>>> > Tim Ruppert
>>>>> > HotWax Media
>>>>> > http://www.hotwaxmedia.com
>>>>> >
>>>>> > o:801.649.6594
>>>>> > f:801.649.6595
>>>>> >
>>>>> >
>>>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>>>>> >
>>>>> > From my perspective, having two 4ths and only 29 days in
>>>>> November is a
>>>>> > bug.
>>>>> >
>>>>> > David E Jones wrote:
>>>>> >
>>>>> > I don't know... that's a fairly big change and in a very real way
>>>>> > supporting DST changes is a new feature...
>>>>> > That's my opinion anyway. Doesn't this also depend on a fair
>>>>> amount of
>>>>> > other new functionality?
>>>>> > -David
>>>>> > Adrian Crum wrote:
>>>>> >
>>>>> > Scott,
>>>>> >
>>>>> > This isn't already committed, but it needs to go into both -
>>>>> >
>>>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>>>>> >
>>>>> > -Adrian
>>>>> >
>>>>> > Scott Gray wrote:
>>>>> >
>>>>> > Hi All,
>>>>> >
>>>>> > I'll be reviewing the last fortnight's trunk commits for merging
>>>>> back to
>>>>> > the
>>>>> > release branch tonight, so if anyone knows of any trunk commits
>>>>> that
>>>>> > should
>>>>> > be merged it would be great if you could post them here.
>>>>> >
>>>>> > Thanks
>>>>> > Scott
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>
>>
Re: Workeffort Bug vs New Feature
Posted by Adrian Crum <ad...@hlmksw.com>.
Jacopo,
I'm relaxed and positive. I'm just being what Americans call "snarky." Hence the ;)
Here's another one in case anyone missed it
;)
-Adrian
Jacopo Cappellato wrote:
> Adrian,
>
> in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079 should not.
> However I really think that it is very important to maintain a relaxed,
> positive and constructive attitude between us especially when we
> disagree or have different opinion.
>
> Jacopo
>
>
> Adrian Crum wrote:
>
>> David E Jones wrote:
>>
>>>
>>> The primary goal of a release branch is to stabilize current
>>> functionality.
>>>
>>> Generally a very important part of that is to not introduce new
>>> functionality that might cause new bugs. That doesn't mean everything
>>> one might want or that might be implied in the data model or other
>>> parts of the system will work as expected, it just means that
>>> everything that IS implemented will function.
>>>
>>> Some things are difficult to decide on, but remember the first
>>> priority is stabilization.
>>>
>>> -David
>>
>>
>> In other words, it's okay for the system to function incorrectly, as
>> long as it consistently functions incorrectly.
>>
>> ;)
>>
>> If you prefer to keep the Workeffort calendar broken, that's fine with
>> me. When new users ask why release version 4 has only 29 days in
>> November, I can point them to this discussion and let them know that
>> November 30th was a new feature that didn't make it into the release.
>>
>>>
>>>
>>> Adrian Crum wrote:
>>>
>>>> Moving this to a new thread. I apologize for the threadjack Scott.
>>>>
>>>> I'm puzzled. A Workeffort screen displays a calendar incorrectly and
>>>> I submit a patch that fixes it. How is that a new feature?
>>>>
>>>> It sounds to me like bug fixes are okay as long as they don't
>>>> introduce new code. What if fixing a bug requires new code?
>>>>
>>>>
>>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>
>>>> >
>>>> > Then I guess it depends on whether or not the rest of the fix is
>>>> indeed
>>>> > fixing a bug or new features :)
>>>> >
>>>> > Cheers,
>>>> > Tim
>>>> > --
>>>> > Tim Ruppert
>>>> > HotWax Media
>>>> > http://www.hotwaxmedia.com
>>>> >
>>>> > o:801.649.6594
>>>> > f:801.649.6595
>>>> >
>>>> >
>>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>>>> >
>>>> > From my perspective, having two 4ths and only 29 days in November
>>>> is a
>>>> > bug.
>>>> >
>>>> > David E Jones wrote:
>>>> >
>>>> > I don't know... that's a fairly big change and in a very real way
>>>> > supporting DST changes is a new feature...
>>>> > That's my opinion anyway. Doesn't this also depend on a fair
>>>> amount of
>>>> > other new functionality?
>>>> > -David
>>>> > Adrian Crum wrote:
>>>> >
>>>> > Scott,
>>>> >
>>>> > This isn't already committed, but it needs to go into both -
>>>> >
>>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>>>> >
>>>> > -Adrian
>>>> >
>>>> > Scott Gray wrote:
>>>> >
>>>> > Hi All,
>>>> >
>>>> > I'll be reviewing the last fortnight's trunk commits for merging
>>>> back to
>>>> > the
>>>> > release branch tonight, so if anyone knows of any trunk commits that
>>>> > should
>>>> > be merged it would be great if you could post them here.
>>>> >
>>>> > Thanks
>>>> > Scott
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>
>
Re: Workeffort Bug vs New Feature
Posted by Vince Clark <vc...@globalera.com>.
Nothing wrong with a bit of sarcastic humor. I'm sure we can all take it.
Adrian, please put me down +1 for the new feature "November 30th."
Jacopo Cappellato wrote:
> Adrian,
>
> in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079 should not.
> However I really think that it is very important to maintain a
> relaxed, positive and constructive attitude between us especially when
> we disagree or have different opinion.
>
> Jacopo
>
>
> Adrian Crum wrote:
>> David E Jones wrote:
>>>
>>> The primary goal of a release branch is to stabilize current
>>> functionality.
>>>
>>> Generally a very important part of that is to not introduce new
>>> functionality that might cause new bugs. That doesn't mean
>>> everything one might want or that might be implied in the data model
>>> or other parts of the system will work as expected, it just means
>>> that everything that IS implemented will function.
>>>
>>> Some things are difficult to decide on, but remember the first
>>> priority is stabilization.
>>>
>>> -David
>>
>> In other words, it's okay for the system to function incorrectly, as
>> long as it consistently functions incorrectly.
>>
>> ;)
>>
>> If you prefer to keep the Workeffort calendar broken, that's fine
>> with me. When new users ask why release version 4 has only 29 days in
>> November, I can point them to this discussion and let them know that
>> November 30th was a new feature that didn't make it into the release.
>>
>>>
>>>
>>> Adrian Crum wrote:
>>>
>>>> Moving this to a new thread. I apologize for the threadjack Scott.
>>>>
>>>> I'm puzzled. A Workeffort screen displays a calendar incorrectly
>>>> and I submit a patch that fixes it. How is that a new feature?
>>>>
>>>> It sounds to me like bug fixes are okay as long as they don't
>>>> introduce new code. What if fixing a bug requires new code?
>>>>
>>>>
>>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>
>>>> >
>>>> > Then I guess it depends on whether or not the rest of the fix is
>>>> indeed
>>>> > fixing a bug or new features :)
>>>> >
>>>> > Cheers,
>>>> > Tim
>>>> > --
>>>> > Tim Ruppert
>>>> > HotWax Media
>>>> > http://www.hotwaxmedia.com
>>>> >
>>>> > o:801.649.6594
>>>> > f:801.649.6595
>>>> >
>>>> >
>>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>>>> >
>>>> > From my perspective, having two 4ths and only 29 days in
>>>> November is a
>>>> > bug.
>>>> >
>>>> > David E Jones wrote:
>>>> >
>>>> > I don't know... that's a fairly big change and in a very real way
>>>> > supporting DST changes is a new feature...
>>>> > That's my opinion anyway. Doesn't this also depend on a fair
>>>> amount of
>>>> > other new functionality?
>>>> > -David
>>>> > Adrian Crum wrote:
>>>> >
>>>> > Scott,
>>>> >
>>>> > This isn't already committed, but it needs to go into both -
>>>> >
>>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>>>> >
>>>> > -Adrian
>>>> >
>>>> > Scott Gray wrote:
>>>> >
>>>> > Hi All,
>>>> >
>>>> > I'll be reviewing the last fortnight's trunk commits for merging
>>>> back to
>>>> > the
>>>> > release branch tonight, so if anyone knows of any trunk commits
>>>> that
>>>> > should
>>>> > be merged it would be great if you could post them here.
>>>> >
>>>> > Thanks
>>>> > Scott
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>
--
Vince Clark
Global Era
The freedom of open source.
(303) 493-6723
(303) 455-2409 fax
vclark@globalera.com <ma...@globalera.com>
www.globalera.com
Re: Workeffort Bug vs New Feature
Posted by Jacopo Cappellato <ti...@sastau.it>.
Adrian,
in my opinion OFBIZ-1069 could go in the release; OFBIZ-1079 should not.
However I really think that it is very important to maintain a relaxed,
positive and constructive attitude between us especially when we
disagree or have different opinion.
Jacopo
Adrian Crum wrote:
> David E Jones wrote:
>>
>> The primary goal of a release branch is to stabilize current
>> functionality.
>>
>> Generally a very important part of that is to not introduce new
>> functionality that might cause new bugs. That doesn't mean everything
>> one might want or that might be implied in the data model or other
>> parts of the system will work as expected, it just means that
>> everything that IS implemented will function.
>>
>> Some things are difficult to decide on, but remember the first
>> priority is stabilization.
>>
>> -David
>
> In other words, it's okay for the system to function incorrectly, as
> long as it consistently functions incorrectly.
>
> ;)
>
> If you prefer to keep the Workeffort calendar broken, that's fine with
> me. When new users ask why release version 4 has only 29 days in
> November, I can point them to this discussion and let them know that
> November 30th was a new feature that didn't make it into the release.
>
>>
>>
>> Adrian Crum wrote:
>>
>>> Moving this to a new thread. I apologize for the threadjack Scott.
>>>
>>> I'm puzzled. A Workeffort screen displays a calendar incorrectly and
>>> I submit a patch that fixes it. How is that a new feature?
>>>
>>> It sounds to me like bug fixes are okay as long as they don't
>>> introduce new code. What if fixing a bug requires new code?
>>>
>>>
>>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>
>>> >
>>> > Then I guess it depends on whether or not the rest of the fix is
>>> indeed
>>> > fixing a bug or new features :)
>>> >
>>> > Cheers,
>>> > Tim
>>> > --
>>> > Tim Ruppert
>>> > HotWax Media
>>> > http://www.hotwaxmedia.com
>>> >
>>> > o:801.649.6594
>>> > f:801.649.6595
>>> >
>>> >
>>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>>> >
>>> > From my perspective, having two 4ths and only 29 days in November
>>> is a
>>> > bug.
>>> >
>>> > David E Jones wrote:
>>> >
>>> > I don't know... that's a fairly big change and in a very real way
>>> > supporting DST changes is a new feature...
>>> > That's my opinion anyway. Doesn't this also depend on a fair
>>> amount of
>>> > other new functionality?
>>> > -David
>>> > Adrian Crum wrote:
>>> >
>>> > Scott,
>>> >
>>> > This isn't already committed, but it needs to go into both -
>>> >
>>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>>> >
>>> > -Adrian
>>> >
>>> > Scott Gray wrote:
>>> >
>>> > Hi All,
>>> >
>>> > I'll be reviewing the last fortnight's trunk commits for merging
>>> back to
>>> > the
>>> > release branch tonight, so if anyone knows of any trunk commits that
>>> > should
>>> > be merged it would be great if you could post them here.
>>> >
>>> > Thanks
>>> > Scott
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>
Re: Workeffort Bug vs New Feature
Posted by Adrian Crum <ad...@hlmksw.com>.
The bug fix uses the new methods in UtilDateTime.java. The existing code performs date calculations
by doing arithmetic on millisecond values. That simply doesn't work. If it did, there would be no
need for classes like java.util.Calendar and java.util.TimeZone.
I get the feeling the objections are being raised over the new UtilDateTime.java methods. I've been
using the new methods here for about a month. I have a calendar component that uses them and it
works flawlessly across time zones, locales, and DST changes.
Chris Howe wrote:
> --- Adrian Crum <ad...@hlmksw.com> wrote:
>
>>In other words, it's okay for the system to function incorrectly, as
>>long as it consistently
>>functions incorrectly.
>>
>>;)
>>
>>If you prefer to keep the Workeffort calendar broken, that's fine
>>with me. When new users ask why
>>release version 4 has only 29 days in November, I can point them to
>>this discussion and let them
>>know that November 30th was a new feature that didn't make it into
>>the release.
>>
>
>
> Can't wait to see that on a change log somewhere :-). Since there is
> calendar usage in 4.0 (Rental and Manufacturing to my knowledge) I see
> the issue as a bug fix. I think the question really is, how much of
> the solution is new feature and how much of it bug fix. Can you get
> the correct number of days in November without the entire solution?
>
>
>
Re: Workeffort Bug vs New Feature
Posted by Chris Howe <cj...@yahoo.com>.
--- Adrian Crum <ad...@hlmksw.com> wrote:
>
> In other words, it's okay for the system to function incorrectly, as
> long as it consistently
> functions incorrectly.
>
> ;)
>
> If you prefer to keep the Workeffort calendar broken, that's fine
> with me. When new users ask why
> release version 4 has only 29 days in November, I can point them to
> this discussion and let them
> know that November 30th was a new feature that didn't make it into
> the release.
>
Can't wait to see that on a change log somewhere :-). Since there is
calendar usage in 4.0 (Rental and Manufacturing to my knowledge) I see
the issue as a bug fix. I think the question really is, how much of
the solution is new feature and how much of it bug fix. Can you get
the correct number of days in November without the entire solution?
Re: Workeffort Bug vs New Feature
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
>
> The primary goal of a release branch is to stabilize current functionality.
>
> Generally a very important part of that is to not introduce new
> functionality that might cause new bugs. That doesn't mean everything
> one might want or that might be implied in the data model or other parts
> of the system will work as expected, it just means that everything that
> IS implemented will function.
>
> Some things are difficult to decide on, but remember the first priority
> is stabilization.
>
> -David
In other words, it's okay for the system to function incorrectly, as long as it consistently
functions incorrectly.
;)
If you prefer to keep the Workeffort calendar broken, that's fine with me. When new users ask why
release version 4 has only 29 days in November, I can point them to this discussion and let them
know that November 30th was a new feature that didn't make it into the release.
>
>
> Adrian Crum wrote:
>
>> Moving this to a new thread. I apologize for the threadjack Scott.
>>
>> I'm puzzled. A Workeffort screen displays a calendar incorrectly and I
>> submit a patch that fixes it. How is that a new feature?
>>
>> It sounds to me like bug fixes are okay as long as they don't
>> introduce new code. What if fixing a bug requires new code?
>>
>>
>> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>
>> >
>> > Then I guess it depends on whether or not the rest of the fix is
>> indeed
>> > fixing a bug or new features :)
>> >
>> > Cheers,
>> > Tim
>> > --
>> > Tim Ruppert
>> > HotWax Media
>> > http://www.hotwaxmedia.com
>> >
>> > o:801.649.6594
>> > f:801.649.6595
>> >
>> >
>> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
>> >
>> > From my perspective, having two 4ths and only 29 days in November is a
>> > bug.
>> >
>> > David E Jones wrote:
>> >
>> > I don't know... that's a fairly big change and in a very real way
>> > supporting DST changes is a new feature...
>> > That's my opinion anyway. Doesn't this also depend on a fair amount of
>> > other new functionality?
>> > -David
>> > Adrian Crum wrote:
>> >
>> > Scott,
>> >
>> > This isn't already committed, but it needs to go into both -
>> >
>> > https://issues.apache.org/jira/browse/OFBIZ-1069
>> >
>> > -Adrian
>> >
>> > Scott Gray wrote:
>> >
>> > Hi All,
>> >
>> > I'll be reviewing the last fortnight's trunk commits for merging
>> back to
>> > the
>> > release branch tonight, so if anyone knows of any trunk commits that
>> > should
>> > be merged it would be great if you could post them here.
>> >
>> > Thanks
>> > Scott
>> >
>> >
>> >
>> >
>>
>>
>
Re: Workeffort Bug vs New Feature
Posted by David E Jones <jo...@hotwaxmedia.com>.
The primary goal of a release branch is to stabilize current functionality.
Generally a very important part of that is to not introduce new functionality that might cause new bugs. That doesn't mean everything one might want or that might be implied in the data model or other parts of the system will work as expected, it just means that everything that IS implemented will function.
Some things are difficult to decide on, but remember the first priority is stabilization.
-David
Adrian Crum wrote:
> Moving this to a new thread. I apologize for the threadjack Scott.
>
> I'm puzzled. A Workeffort screen displays a calendar incorrectly and I
> submit a patch that fixes it. How is that a new feature?
>
> It sounds to me like bug fixes are okay as long as they don't introduce
> new code. What if fixing a bug requires new code?
>
>
> On 15/06/07, Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>
> >
> > Then I guess it depends on whether or not the rest of the fix is indeed
> > fixing a bug or new features :)
> >
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> >
> > o:801.649.6594
> > f:801.649.6595
> >
> >
> > On Jun 14, 2007, at 2:19 PM, Adrian Crum wrote:
> >
> > From my perspective, having two 4ths and only 29 days in November is a
> > bug.
> >
> > David E Jones wrote:
> >
> > I don't know... that's a fairly big change and in a very real way
> > supporting DST changes is a new feature...
> > That's my opinion anyway. Doesn't this also depend on a fair amount of
> > other new functionality?
> > -David
> > Adrian Crum wrote:
> >
> > Scott,
> >
> > This isn't already committed, but it needs to go into both -
> >
> > https://issues.apache.org/jira/browse/OFBIZ-1069
> >
> > -Adrian
> >
> > Scott Gray wrote:
> >
> > Hi All,
> >
> > I'll be reviewing the last fortnight's trunk commits for merging back to
> > the
> > release branch tonight, so if anyone knows of any trunk commits that
> > should
> > be merged it would be great if you could post them here.
> >
> > Thanks
> > Scott
> >
> >
> >
> >
>
>