Workeffort Bug vs New Feature
Locked
 
|
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 <[hidden email]> 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
|
|
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 <[hidden email]> 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
|
|
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 <[hidden email]> 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 >> > >> > >> > >> > >> >> > |
|
|
--- Adrian Crum <[hidden email]> 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
|
|
In reply to this post by Adrian Crum
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 <[hidden email]> 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
|
|
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 <[hidden email]> 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
|
|
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 o:801.649.6594 f:801.649.6595 On Jun 14, 2007, at 3:29 PM, Adrian Crum wrote:
|
smime.p7s (3K)
Re: Workeffort Bug vs New Feature
|
|
In reply to this post by Jacopo Cappellato
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 <[hidden email]> 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 [hidden email] <mailto:[hidden email]> www.globalera.com |
Re: Workeffort Bug vs New Feature
|
|
In reply to this post by Jacopo Cappellato
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 <[hidden email]> 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
|
|
In reply to this post by cjhowe
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 <[hidden email]> 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? > > > |
|
|
In reply to this post by Adrian Crum
I don't have a problem with this going into 4.0
Regards Scott On 15/06/07, Adrian Crum <[hidden email]> 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 <[hidden email]> 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
|
|
In reply to this post by Adrian Crum
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 <[hidden email]> 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
|
|
In reply to this post by Adrian Crum
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 <[hidden email]> 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
|
|
In reply to this post by Adrian Crum
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 [hidden email] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.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. > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |