release?
Locked
123
123
 
|
+1
David E. Jones wrote: > > Should we just set a date so everyone knows it's coming, and then just > go for it? > > How about this Friday? > > -David > > > On Apr 17, 2007, at 11:05 AM, David E. Jones wrote: > >> >> I'm just concerned because most of the discussion seems to be related >> to things that are already in the Release Plan. >> >> So, maybe we need a thread for a RFC on the Release Plan first? >> >> The big point of the release plan that everyone seems to agree on is, >> let's just do the branch! The point of the plan is to handle it not >> being perfect on day 1, etc. >> >> -David >> >> >> On Apr 17, 2007, at 11:58 AM, BJ Freeman wrote: >> >>> I have read the release plan, however it has been there for a while and >>> we can't seem to get to the next step of implementing. >>> I am guessing everyone is saying lets get a move on. >>> Action >>> >>> David E. Jones sent the following on 4/17/2007 8:55 AM: >>> >>>> >>>> This is a very relevant topic, but it might be helpful to in terms of >>>> the existing Release Plan: >>>> >>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan >>>> >>>> I don't see people referring to this much or talking in terms of "this >>>> is the plan, but maybe we should do it X way because of Y". Is that >>>> because the Release Plan is just total crap, or maybe it's too long >>>> and >>>> not worth reading? >>>> >>>> But yeah, these things are addressed in the Release Plan. >>>> >>>> -David >>>> >>>> >>>> On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote: >>>> >>>>> What about simply forking a release branch now, and then we work on >>>>> stabilizing and debugging THAT branch? >>>>> >>>>> As and when new fixes go into the trunk, we can merge those fixes >>>>> into >>>>> the branch. Ideally, the release branch will not take in new features >>>>> from the trunk, but only fixes to bring the branch towards stability >>>>> for final release. I'd recommend using Release Candidates. >>>>> >>>>> I'd be the first one to offer to test the release branch in the >>>>> effort >>>>> to bring it to release status. If there _is_ a release branch, >>>>> I'll be >>>>> basing my work on that branch rather than the trunk, anyway. >>>>> >>>>> If no one else is familiar with this branching strategy, I may be >>>>> willing to take on the admin work for this. Just let me know when my >>>>> deadlines and what my deliverables will be. >>>>> >>>>> Jonathon >>>>> >>>>> Si Chen wrote: >>>>> >>>>>> The SVN right now is in reasonably good shape in my opinion -- it's >>>>>> been more stable in the past, but there's also been a lot of times >>>>>> when it's a lot less stable. I think we need to get the >>>>>> framework to >>>>>> a stable point and resolve any critical applications bugs, and then >>>>>> it should be a pretty good release. >>>>>> Having said that, is it better to create a release branch now, or >>>>>> wait a little bit? This would depend on everybody's development >>>>>> plans. I notice David and Andy are doing a lot of things in the >>>>>> framework and base methods and that there have been some bugs that >>>>>> are being fixed. Could the next few days, week, or two weeks be >>>>>> spent primarily addressing these issues without a lot of new >>>>>> features >>>>>> being committed? If so, then it'd be better to wait until then. >>>>>> Otherwise, let's just make the release branch before a whole >>>>>> bunch of >>>>>> new but not necessarily critical features or refactorings arrive. >>>>>> Shi Yusen wrote: >>>>>> >>>>>>> +1 for creating a release branch. >>>>>>> >>>>>>> >>>>>>>> Also, without responses the branch will basically just include >>>>>>>> whatever it includes. >>>>>>>> >>>>>>> As an training course, I have arranged a man to test current >>>>>>> HEAD in >>>>>>> different enviroments. >>>>>>> >>>>>>> I think the release branch can be created now. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Shi Yusen/Beijing Langhua Ltd. >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> ------ >>>>>> No virus found in this incoming message. >>>>>> Checked by AVG Free Edition. >>>>>> Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date: >>>>>> 4/16/2007 5:53 PM >>>>> >>>>> >>>> >> > |
|
|
In reply to this post by BJ Freeman
David,
what needs to be said on the release Plan, for it to be implemented? BJ Freeman sent the following on 4/17/2007 9:58 AM: > I have read the release plan, however it has been there for a while and > we can't seem to get to the next step of implementing. > I am guessing everyone is saying lets get a move on. > Action > > David E. Jones sent the following on 4/17/2007 8:55 AM: >> This is a very relevant topic, but it might be helpful to in terms of >> the existing Release Plan: >> >> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan >> >> I don't see people referring to this much or talking in terms of "this >> is the plan, but maybe we should do it X way because of Y". Is that >> because the Release Plan is just total crap, or maybe it's too long and >> not worth reading? >> >> But yeah, these things are addressed in the Release Plan. >> >> -David >> >> >> On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote: >> >>> What about simply forking a release branch now, and then we work on >>> stabilizing and debugging THAT branch? >>> >>> As and when new fixes go into the trunk, we can merge those fixes into >>> the branch. Ideally, the release branch will not take in new features >>> from the trunk, but only fixes to bring the branch towards stability >>> for final release. I'd recommend using Release Candidates. >>> >>> I'd be the first one to offer to test the release branch in the effort >>> to bring it to release status. If there _is_ a release branch, I'll be >>> basing my work on that branch rather than the trunk, anyway. >>> >>> If no one else is familiar with this branching strategy, I may be >>> willing to take on the admin work for this. Just let me know when my >>> deadlines and what my deliverables will be. >>> >>> Jonathon >>> >>> Si Chen wrote: >>>> The SVN right now is in reasonably good shape in my opinion -- it's >>>> been more stable in the past, but there's also been a lot of times >>>> when it's a lot less stable. I think we need to get the framework to >>>> a stable point and resolve any critical applications bugs, and then >>>> it should be a pretty good release. >>>> Having said that, is it better to create a release branch now, or >>>> wait a little bit? This would depend on everybody's development >>>> plans. I notice David and Andy are doing a lot of things in the >>>> framework and base methods and that there have been some bugs that >>>> are being fixed. Could the next few days, week, or two weeks be >>>> spent primarily addressing these issues without a lot of new features >>>> being committed? If so, then it'd be better to wait until then. >>>> Otherwise, let's just make the release branch before a whole bunch of >>>> new but not necessarily critical features or refactorings arrive. >>>> Shi Yusen wrote: >>>>> +1 for creating a release branch. >>>>> >>>>> >>>>>> Also, without responses the branch will basically just include >>>>>> whatever it includes. >>>>>> >>>>> As an training course, I have arranged a man to test current HEAD in >>>>> different enviroments. >>>>> >>>>> I think the release branch can be created now. >>>>> >>>>> Regards, >>>>> >>>>> Shi Yusen/Beijing Langhua Ltd. >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date: >>>> 4/16/2007 5:53 PM > > > |
|
|
In reply to this post by Adrian Crum
What are we voting on?
On 4/17/07, Adrian Crum <[hidden email]> wrote: > > +1 > > David E. Jones wrote: > > > > > Should we just set a date so everyone knows it's coming, and then just > > go for it? > > > > How about this Friday? > > > > -David > > > > > > On Apr 17, 2007, at 11:05 AM, David E. Jones wrote: > > > >> > >> I'm just concerned because most of the discussion seems to be related > >> to things that are already in the Release Plan. > >> > >> So, maybe we need a thread for a RFC on the Release Plan first? > >> > >> The big point of the release plan that everyone seems to agree on is, > >> let's just do the branch! The point of the plan is to handle it not > >> being perfect on day 1, etc. > >> > >> -David > >> > >> > >> On Apr 17, 2007, at 11:58 AM, BJ Freeman wrote: > >> > >>> I have read the release plan, however it has been there for a while > and > >>> we can't seem to get to the next step of implementing. > >>> I am guessing everyone is saying lets get a move on. > >>> Action > >>> > >>> David E. Jones sent the following on 4/17/2007 8:55 AM: > >>> > >>>> > >>>> This is a very relevant topic, but it might be helpful to in terms > of > >>>> the existing Release Plan: > >>>> > >>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan > >>>> > >>>> I don't see people referring to this much or talking in terms > of "this > >>>> is the plan, but maybe we should do it X way because of Y". Is that > >>>> because the Release Plan is just total crap, or maybe it's too long > >>>> and > >>>> not worth reading? > >>>> > >>>> But yeah, these things are addressed in the Release Plan. > >>>> > >>>> -David > >>>> > >>>> > >>>> On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote: > >>>> > >>>>> What about simply forking a release branch now, and then we work on > >>>>> stabilizing and debugging THAT branch? > >>>>> > >>>>> As and when new fixes go into the trunk, we can merge those fixes > >>>>> into > >>>>> the branch. Ideally, the release branch will not take in > new features > >>>>> from the trunk, but only fixes to bring the branch > towards stability > >>>>> for final release. I'd recommend using Release Candidates. > >>>>> > >>>>> I'd be the first one to offer to test the release branch in the > >>>>> effort > >>>>> to bring it to release status. If there _is_ a release branch, > >>>>> I'll be > >>>>> basing my work on that branch rather than the trunk, anyway. > >>>>> > >>>>> If no one else is familiar with this branching strategy, I may be > >>>>> willing to take on the admin work for this. Just let me know when > my > >>>>> deadlines and what my deliverables will be. > >>>>> > >>>>> Jonathon > >>>>> > >>>>> Si Chen wrote: > >>>>> > >>>>>> The SVN right now is in reasonably good shape in my opinion > -- it's > >>>>>> been more stable in the past, but there's also been a lot of times > >>>>>> when it's a lot less stable. I think we need to get the > >>>>>> framework to > >>>>>> a stable point and resolve any critical applications bugs, > and then > >>>>>> it should be a pretty good release. > >>>>>> Having said that, is it better to create a release branch now, or > >>>>>> wait a little bit? This would depend on everybody's development > >>>>>> plans. I notice David and Andy are doing a lot of things in the > >>>>>> framework and base methods and that there have been some bugs that > >>>>>> are being fixed. Could the next few days, week, or two weeks be > >>>>>> spent primarily addressing these issues without a lot of new > >>>>>> features > >>>>>> being committed? If so, then it'd be better to wait until then. > >>>>>> Otherwise, let's just make the release branch before a whole > >>>>>> bunch of > >>>>>> new but not necessarily critical features or refactorings arrive. > >>>>>> Shi Yusen wrote: > >>>>>> > >>>>>>> +1 for creating a release branch. > >>>>>>> > >>>>>>> > >>>>>>>> Also, without responses the branch will basically just include > >>>>>>>> whatever it includes. > >>>>>>>> > >>>>>>> As an training course, I have arranged a man to test current > >>>>>>> HEAD in > >>>>>>> different enviroments. > >>>>>>> > >>>>>>> I think the release branch can be created now. > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Shi Yusen/Beijing Langhua Ltd. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> ------------------------------------------------------------------ > >>>>>> ------ > >>>>>> No virus found in this incoming message. > >>>>>> Checked by AVG Free Edition. > >>>>>> Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date: > >>>>>> 4/16/2007 5:53 PM > >>>>> > >>>>> > >>>> > >> > > > |
|
|
Anil Patel wrote:
> What are we voting on? Creating a branch this Friday so we can start working on a release. |
|
|
In reply to this post by BJ Freeman
I like the information that the struts project has on their release plan
page. Maybe something similar? http://struts.apache.org/2.x/docs/release-plan-201.html Mike BJ Freeman wrote: > David, > what needs to be said on the release Plan, for it to be implemented? > > BJ Freeman sent the following on 4/17/2007 9:58 AM: >> I have read the release plan, however it has been there for a while and >> we can't seem to get to the next step of implementing. >> I am guessing everyone is saying lets get a move on. >> Action >> >> David E. Jones sent the following on 4/17/2007 8:55 AM: >>> This is a very relevant topic, but it might be helpful to in terms of >>> the existing Release Plan: >>> >>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan >>> >>> I don't see people referring to this much or talking in terms of "this >>> is the plan, but maybe we should do it X way because of Y". Is that >>> because the Release Plan is just total crap, or maybe it's too long and >>> not worth reading? >>> >>> But yeah, these things are addressed in the Release Plan. >>> >>> -David >>> >>> >>> On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote: >>> >>>> What about simply forking a release branch now, and then we work on >>>> stabilizing and debugging THAT branch? >>>> >>>> As and when new fixes go into the trunk, we can merge those fixes into >>>> the branch. Ideally, the release branch will not take in new features >>>> from the trunk, but only fixes to bring the branch towards stability >>>> for final release. I'd recommend using Release Candidates. >>>> >>>> I'd be the first one to offer to test the release branch in the effort >>>> to bring it to release status. If there _is_ a release branch, I'll be >>>> basing my work on that branch rather than the trunk, anyway. >>>> >>>> If no one else is familiar with this branching strategy, I may be >>>> willing to take on the admin work for this. Just let me know when my >>>> deadlines and what my deliverables will be. >>>> >>>> Jonathon >>>> >>>> Si Chen wrote: >>>>> The SVN right now is in reasonably good shape in my opinion -- it's >>>>> been more stable in the past, but there's also been a lot of times >>>>> when it's a lot less stable. I think we need to get the framework to >>>>> a stable point and resolve any critical applications bugs, and then >>>>> it should be a pretty good release. >>>>> Having said that, is it better to create a release branch now, or >>>>> wait a little bit? This would depend on everybody's development >>>>> plans. I notice David and Andy are doing a lot of things in the >>>>> framework and base methods and that there have been some bugs that >>>>> are being fixed. Could the next few days, week, or two weeks be >>>>> spent primarily addressing these issues without a lot of new features >>>>> being committed? If so, then it'd be better to wait until then. >>>>> Otherwise, let's just make the release branch before a whole bunch of >>>>> new but not necessarily critical features or refactorings arrive. >>>>> Shi Yusen wrote: >>>>>> +1 for creating a release branch. >>>>>> >>>>>> >>>>>>> Also, without responses the branch will basically just include >>>>>>> whatever it includes. >>>>>>> >>>>>> As an training course, I have arranged a man to test current HEAD in >>>>>> different enviroments. >>>>>> >>>>>> I think the release branch can be created now. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Shi Yusen/Beijing Langhua Ltd. >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> No virus found in this incoming message. >>>>> Checked by AVG Free Edition. >>>>> Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date: >>>>> 4/16/2007 5:53 PM >> >> -- Millcreek Systems, Inc. P.O. Box 9835 Salt Lake City, Utah 84109 Phone: 801.649.4903 Skype: millcreeksys (http://millcreeksys.com/skype/) |
|
|
+1 for a branch on Friday
and also the release plan looks fine to me Regards Scott On 18/04/07, Michael Jensen <[hidden email]> wrote: > > I like the information that the struts project has on their release plan > page. Maybe something similar? > http://struts.apache.org/2.x/docs/release-plan-201.html > > Mike > > BJ Freeman wrote: > > David, > > what needs to be said on the release Plan, for it to be implemented? > > > > BJ Freeman sent the following on 4/17/2007 9:58 AM: > >> I have read the release plan, however it has been there for a while and > >> we can't seem to get to the next step of implementing. > >> I am guessing everyone is saying lets get a move on. > >> Action > >> > >> David E. Jones sent the following on 4/17/2007 8:55 AM: > >>> This is a very relevant topic, but it might be helpful to in terms of > >>> the existing Release Plan: > >>> > >>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan > >>> > >>> I don't see people referring to this much or talking in terms of "this > >>> is the plan, but maybe we should do it X way because of Y". Is that > >>> because the Release Plan is just total crap, or maybe it's too long > and > >>> not worth reading? > >>> > >>> But yeah, these things are addressed in the Release Plan. > >>> > >>> -David > >>> > >>> > >>> On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote: > >>> > >>>> What about simply forking a release branch now, and then we work on > >>>> stabilizing and debugging THAT branch? > >>>> > >>>> As and when new fixes go into the trunk, we can merge those fixes > into > >>>> the branch. Ideally, the release branch will not take in new features > >>>> from the trunk, but only fixes to bring the branch towards stability > >>>> for final release. I'd recommend using Release Candidates. > >>>> > >>>> I'd be the first one to offer to test the release branch in the > effort > >>>> to bring it to release status. If there _is_ a release branch, I'll > be > >>>> basing my work on that branch rather than the trunk, anyway. > >>>> > >>>> If no one else is familiar with this branching strategy, I may be > >>>> willing to take on the admin work for this. Just let me know when my > >>>> deadlines and what my deliverables will be. > >>>> > >>>> Jonathon > >>>> > >>>> Si Chen wrote: > >>>>> The SVN right now is in reasonably good shape in my opinion -- it's > >>>>> been more stable in the past, but there's also been a lot of times > >>>>> when it's a lot less stable. I think we need to get the framework > to > >>>>> a stable point and resolve any critical applications bugs, and then > >>>>> it should be a pretty good release. > >>>>> Having said that, is it better to create a release branch now, or > >>>>> wait a little bit? This would depend on everybody's development > >>>>> plans. I notice David and Andy are doing a lot of things in the > >>>>> framework and base methods and that there have been some bugs that > >>>>> are being fixed. Could the next few days, week, or two weeks be > >>>>> spent primarily addressing these issues without a lot of new > features > >>>>> being committed? If so, then it'd be better to wait until then. > >>>>> Otherwise, let's just make the release branch before a whole bunch > of > >>>>> new but not necessarily critical features or refactorings arrive. > >>>>> Shi Yusen wrote: > >>>>>> +1 for creating a release branch. > >>>>>> > >>>>>> > >>>>>>> Also, without responses the branch will basically just include > >>>>>>> whatever it includes. > >>>>>>> > >>>>>> As an training course, I have arranged a man to test current HEAD > in > >>>>>> different enviroments. > >>>>>> > >>>>>> I think the release branch can be created now. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Shi Yusen/Beijing Langhua Ltd. > >>>>>> > >>>>>> > >>>>>> > >>>>> > ------------------------------------------------------------------------ > >>>>> No virus found in this incoming message. > >>>>> Checked by AVG Free Edition. > >>>>> Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date: > >>>>> 4/16/2007 5:53 PM > >> > >> > > -- > Millcreek Systems, Inc. > P.O. Box 9835 > Salt Lake City, Utah 84109 > Phone: 801.649.4903 > Skype: millcreeksys (http://millcreeksys.com/skype/) > |
|
|
In reply to this post by David E Jones
David,
Probably because the plan describes the branching strategy just vaguely and assumes everybody knows the details? The strategy described is commonplace and tested, so I second it. Here's probably the missing piece of info that some folks are looking for, to get confidence in starting the branch? Every update to the trunk should be monitored by the person managing the release branch. Each update to trunk should be quickly assessed to see if it applies to the branch (some simple criteria being "whether the application is for a new feature or existing bugs"). If it applies to branch, then apply it. And vice versa. Every update or bugfix to the branch should be assessed to see if it applies to trunk. That way, all fixes done on today's releases will be carried forward to tomorrow's releases. Hope that assures everybody that "anytime, really, is a good time to branch for release". By the way, we may often find ourselves having to apply just a sub-part of a patch to trunk. So, `svn merge -r ${revision-1}:${revison} http://svn.apache.org/repos/asf/incubator/ofbiz/trunk' may not always work, but may even create new bugs in the release branch instead. Also, over time, as the release branch and trunk diverges, the release branch maintainers could complain that it's too difficult to "apply apples to oranges". And that should be the time to discontinue maintenance for that branch. Jonathon David E. Jones wrote: > > This is a very relevant topic, but it might be helpful to in terms of > the existing Release Plan: > > http://docs.ofbiz.org/display/OFBADMIN/Release+Plan > > I don't see people referring to this much or talking in terms of "this > is the plan, but maybe we should do it X way because of Y". Is that > because the Release Plan is just total crap, or maybe it's too long and > not worth reading? > > But yeah, these things are addressed in the Release Plan. > > -David > > > On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote: > >> What about simply forking a release branch now, and then we work on >> stabilizing and debugging THAT branch? >> >> As and when new fixes go into the trunk, we can merge those fixes into >> the branch. Ideally, the release branch will not take in new features >> from the trunk, but only fixes to bring the branch towards stability >> for final release. I'd recommend using Release Candidates. >> >> I'd be the first one to offer to test the release branch in the effort >> to bring it to release status. If there _is_ a release branch, I'll be >> basing my work on that branch rather than the trunk, anyway. >> >> If no one else is familiar with this branching strategy, I may be >> willing to take on the admin work for this. Just let me know when my >> deadlines and what my deliverables will be. >> >> Jonathon >> >> Si Chen wrote: >>> The SVN right now is in reasonably good shape in my opinion -- it's >>> been more stable in the past, but there's also been a lot of times >>> when it's a lot less stable. I think we need to get the framework to >>> a stable point and resolve any critical applications bugs, and then >>> it should be a pretty good release. >>> Having said that, is it better to create a release branch now, or >>> wait a little bit? This would depend on everybody's development >>> plans. I notice David and Andy are doing a lot of things in the >>> framework and base methods and that there have been some bugs that >>> are being fixed. Could the next few days, week, or two weeks be >>> spent primarily addressing these issues without a lot of new features >>> being committed? If so, then it'd be better to wait until then. >>> Otherwise, let's just make the release branch before a whole bunch of >>> new but not necessarily critical features or refactorings arrive. >>> Shi Yusen wrote: >>>> +1 for creating a release branch. >>>> >>>> >>>>> Also, without responses the branch will basically just include >>>>> whatever it includes. >>>>> >>>> As an training course, I have arranged a man to test current HEAD in >>>> different enviroments. >>>> >>>> I think the release branch can be created now. >>>> >>>> Regards, >>>> >>>> Shi Yusen/Beijing Langhua Ltd. >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date: >>> 4/16/2007 5:53 PM >> > |
|
|
In reply to this post by David E Jones
David E. Jones schrieb:
> > Should we just set a date so everyone knows it's coming, and then just > go for it? > > How about this Friday? +1 Christian |
|
|
MINUS 42 votes!!!!
We have *calculation* issues in the Jira issues that need to be either fixed or marked as closed. These are not features. These are places that ofBiz generates incorrect values, stores bad data, and does the wrong thing. Does anyone think that it won't create 10 times more effort to fix these in both a release and trunk branch? Feature lock TODAY. Fix/Close these issues. Branch, then resume the feature/framework changes... jira number affects patch? description 885 accounting no multiple item issuances from different sources generates only one tax adjustment 896 accounting no actions performed after an accepted payment could cause that payment record to be rolled back 876 order calculation yes multiple problems with editing orders that contain promotion items 870 shipping no Shipping Settings in XML don't match Presented Options in New Order Shipping 830 inventory yes problems when receiving inventory for which backorder exists 765 customers no Create New Customer fails if done after initial/aborted anonymous checkout 732 orders no passing "processorder" request can create an order without shipping or payment information 714 accounting no Adding another product to an order with a marketing component product causes mixups in accounting, manufacturing and inventory. 681 accounting no Wrong amount authorized for orders with credit card and billing account 578 order calculation no problems with billing account customer orders 559 order calculation no ability to add a tracking code or campaign to a sales order 482 order calculation yes Invoice generation from order fails if there is a percent item adjustment 424 order calculation no Order edit items/add item blows away item adjustments 314 order calculation no Items in Shopping cart are lost on login. 312 shipping no picklist shows incorrect quantities for out of stock items 224 order calculation no Problem with approximations if the ShoppingCart.basePrice has more than three decimal digits 223 order calculation no CartShipInfo objects are not properly cloned when shopping cart items are exploded. 74 order payment no billing account error in checkout Walter |
|
|
Walter,
I don't think we will ever do a feature lock in OFBiz; the thing closer to a feature lock is a branch where only fixes are applied. Jacopo Walter Vaughan wrote: > MINUS 42 votes!!!! > > We have *calculation* issues in the Jira issues that need to be either > fixed or marked as closed. > > These are not features. These are places that ofBiz generates incorrect > values, stores bad data, and does the wrong thing. > > Does anyone think that it won't create 10 times more effort to fix these > in both a release and trunk branch? > > Feature lock TODAY. Fix/Close these issues. Branch, then resume the > feature/framework changes... > > jira number affects patch? description > 885 accounting no multiple item issuances from different > sources generates only one tax adjustment > 896 accounting no actions performed after an accepted payment > could cause that payment record to be rolled back > 876 order calculation yes multiple problems with editing orders > that contain promotion items > 870 shipping no Shipping Settings in XML don't match Presented > Options in New Order Shipping > 830 inventory yes problems when receiving inventory for which > backorder exists > 765 customers no Create New Customer fails if done after > initial/aborted anonymous checkout > 732 orders no passing "processorder" request can create an > order without shipping or payment information > 714 accounting no Adding another product to an order with a > marketing component product causes mixups in accounting, manufacturing > and inventory. > 681 accounting no Wrong amount authorized for orders with > credit card and billing account > 578 order calculation no problems with billing account customer > orders > 559 order calculation no ability to add a tracking code or > campaign to a sales order > 482 order calculation yes Invoice generation from order fails > if there is a percent item adjustment > 424 order calculation no Order edit items/add item blows away > item adjustments > 314 order calculation no Items in Shopping cart are lost on login. > 312 shipping no picklist shows incorrect quantities for out of > stock items > 224 order calculation no Problem with approximations if the > ShoppingCart.basePrice has more than three decimal digits > 223 order calculation no CartShipInfo objects are not properly > cloned when shopping cart items are exploded. > 74 order payment no billing account error in checkout > > > Walter |
|
|
In reply to this post by Walter Vaughan
Walter,
apart from my previous remark on the approach to follow, I agree with you that it would be great to see these items fixed asap in the trunk, and thanks for your review. After a quick review of the issues in your list, there is a comment I can do: some of the features in OFBiz are not fully implemented (or maintained), so they can be used in limited use cases (and fail with others). For example, billing accounts, as they are currently implemented, are far from perfect and, in a production system, should be used only in limited use cases; fixing/completing the billing account processes will not be an easy task and the maintainers of the release branch could also consider to hide the billing account support to the users, instead of waiting for someone to complete the implementation of them. Does it make sense? Jacopo Walter Vaughan wrote: > MINUS 42 votes!!!! > > We have *calculation* issues in the Jira issues that need to be either > fixed or marked as closed. > > These are not features. These are places that ofBiz generates incorrect > values, stores bad data, and does the wrong thing. > > Does anyone think that it won't create 10 times more effort to fix these > in both a release and trunk branch? > > Feature lock TODAY. Fix/Close these issues. Branch, then resume the > feature/framework changes... > > jira number affects patch? description > 885 accounting no multiple item issuances from different > sources generates only one tax adjustment > 896 accounting no actions performed after an accepted payment > could cause that payment record to be rolled back > 876 order calculation yes multiple problems with editing orders > that contain promotion items > 870 shipping no Shipping Settings in XML don't match Presented > Options in New Order Shipping > 830 inventory yes problems when receiving inventory for which > backorder exists > 765 customers no Create New Customer fails if done after > initial/aborted anonymous checkout > 732 orders no passing "processorder" request can create an > order without shipping or payment information > 714 accounting no Adding another product to an order with a > marketing component product causes mixups in accounting, manufacturing > and inventory. > 681 accounting no Wrong amount authorized for orders with > credit card and billing account > 578 order calculation no problems with billing account customer > orders > 559 order calculation no ability to add a tracking code or > campaign to a sales order > 482 order calculation yes Invoice generation from order fails > if there is a percent item adjustment > 424 order calculation no Order edit items/add item blows away > item adjustments > 314 order calculation no Items in Shopping cart are lost on login. > 312 shipping no picklist shows incorrect quantities for out of > stock items > 224 order calculation no Problem with approximations if the > ShoppingCart.basePrice has more than three decimal digits > 223 order calculation no CartShipInfo objects are not properly > cloned when shopping cart items are exploded. > 74 order payment no billing account error in checkout > > > Walter |
|
|
In reply to this post by Jacopo Cappellato
Walter, Jacopo,
Jacopo is absolutely right. A release branch isn't something ready for release; it's a feature-locked bugfix-only branch which is much easier to bring to stability for release. As long as we don't start the release branch, we won't start fixing more bugs than we create. We won't get a feature freeze/lock. It's not difficult to merge fixes back and forth between trunk and branch. With the slow-moving (no new features) waters in the release branch, we can even isolate and fix bugs easier and faster. No moving target to chase. Jonathon Jacopo Cappellato wrote: > Walter, > > I don't think we will ever do a feature lock in OFBiz; the thing closer > to a feature lock is a branch where only fixes are applied. > > Jacopo > > Walter Vaughan wrote: >> MINUS 42 votes!!!! >> >> We have *calculation* issues in the Jira issues that need to be either >> fixed or marked as closed. >> >> These are not features. These are places that ofBiz generates >> incorrect values, stores bad data, and does the wrong thing. >> >> Does anyone think that it won't create 10 times more effort to fix >> these in both a release and trunk branch? >> >> Feature lock TODAY. Fix/Close these issues. Branch, then resume the >> feature/framework changes... >> >> jira number affects patch? description >> 885 accounting no multiple item issuances from different >> sources generates only one tax adjustment >> 896 accounting no actions performed after an accepted payment >> could cause that payment record to be rolled back >> 876 order calculation yes multiple problems with editing >> orders that contain promotion items >> 870 shipping no Shipping Settings in XML don't match >> Presented Options in New Order Shipping >> 830 inventory yes problems when receiving inventory for which >> backorder exists >> 765 customers no Create New Customer fails if done after >> initial/aborted anonymous checkout >> 732 orders no passing "processorder" request can create an >> order without shipping or payment information >> 714 accounting no Adding another product to an order with a >> marketing component product causes mixups in accounting, manufacturing >> and inventory. >> 681 accounting no Wrong amount authorized for orders with >> credit card and billing account >> 578 order calculation no problems with billing account >> customer orders >> 559 order calculation no ability to add a tracking code or >> campaign to a sales order >> 482 order calculation yes Invoice generation from order fails >> if there is a percent item adjustment >> 424 order calculation no Order edit items/add item blows away >> item adjustments >> 314 order calculation no Items in Shopping cart are lost on >> login. >> 312 shipping no picklist shows incorrect quantities for out >> of stock items >> 224 order calculation no Problem with approximations if the >> ShoppingCart.basePrice has more than three decimal digits >> 223 order calculation no CartShipInfo objects are not >> properly cloned when shopping cart items are exploded. >> 74 order payment no billing account error in checkout >> >> >> Walter > > |
|
|
In reply to this post by Jacopo Cappellato
Jacopo,
+1 for hiding incomplete functions. Such changes to codes (to hide incomplete features) can live (and die) with the release branch, never to be merged into trunk. So, yes, your suggestion makes a lot of sense. Jonathon Jacopo Cappellato wrote: > Walter, > > apart from my previous remark on the approach to follow, I agree with > you that it would be great to see these items fixed asap in the trunk, > and thanks for your review. > > After a quick review of the issues in your list, there is a comment I > can do: some of the features in OFBiz are not fully implemented (or > maintained), so they can be used in limited use cases (and fail with > others). > For example, billing accounts, as they are currently implemented, are > far from perfect and, in a production system, should be used only in > limited use cases; fixing/completing the billing account processes will > not be an easy task and the maintainers of the release branch could also > consider to hide the billing account support to the users, instead of > waiting for someone to complete the implementation of them. > > Does it make sense? > > Jacopo > > > Walter Vaughan wrote: >> MINUS 42 votes!!!! >> >> We have *calculation* issues in the Jira issues that need to be either >> fixed or marked as closed. >> >> These are not features. These are places that ofBiz generates >> incorrect values, stores bad data, and does the wrong thing. >> >> Does anyone think that it won't create 10 times more effort to fix >> these in both a release and trunk branch? >> >> Feature lock TODAY. Fix/Close these issues. Branch, then resume the >> feature/framework changes... >> >> jira number affects patch? description >> 885 accounting no multiple item issuances from different >> sources generates only one tax adjustment >> 896 accounting no actions performed after an accepted payment >> could cause that payment record to be rolled back >> 876 order calculation yes multiple problems with editing >> orders that contain promotion items >> 870 shipping no Shipping Settings in XML don't match >> Presented Options in New Order Shipping >> 830 inventory yes problems when receiving inventory for which >> backorder exists >> 765 customers no Create New Customer fails if done after >> initial/aborted anonymous checkout >> 732 orders no passing "processorder" request can create an >> order without shipping or payment information >> 714 accounting no Adding another product to an order with a >> marketing component product causes mixups in accounting, manufacturing >> and inventory. >> 681 accounting no Wrong amount authorized for orders with >> credit card and billing account >> 578 order calculation no problems with billing account >> customer orders >> 559 order calculation no ability to add a tracking code or >> campaign to a sales order >> 482 order calculation yes Invoice generation from order fails >> if there is a percent item adjustment >> 424 order calculation no Order edit items/add item blows away >> item adjustments >> 314 order calculation no Items in Shopping cart are lost on >> login. >> 312 shipping no picklist shows incorrect quantities for out >> of stock items >> 224 order calculation no Problem with approximations if the >> ShoppingCart.basePrice has more than three decimal digits >> 223 order calculation no CartShipInfo objects are not >> properly cloned when shopping cart items are exploded. >> 74 order payment no billing account error in checkout >> >> >> Walter > > |
Administrator
|
In reply to this post by David E Jones
+1
Jacques > > Should we just set a date so everyone knows it's coming, and then > just go for it? > > How about this Friday? > > -David |
|
Administrator
|
In reply to this post by jonwimp
+1
Jacques > Jacopo, > > +1 for hiding incomplete functions. Such changes to codes (to hide incomplete features) can live > (and die) with the release branch, never to be merged into trunk. > > So, yes, your suggestion makes a lot of sense. > > Jonathon |
|
|
In reply to this post by Jacopo Cappellato
A feature hiding could cause a LOT of problems, and in itself be a new "feature" to maintain... especially for something as critical as billing accounts. If billing accounts were removed it would totally break a to business type of sales cycle which OFBiz generally supports quite well (ie RFQ, quote, order, invoice, payment). The BillingAccounts are used to coordinate the invoicing and payments and track whether or not credit is available for additional sales orders. -David On Apr 18, 2007, at 7:27 AM, Jacopo Cappellato wrote: > Walter, > > apart from my previous remark on the approach to follow, I agree > with you that it would be great to see these items fixed asap in > the trunk, and thanks for your review. > > After a quick review of the issues in your list, there is a comment > I can do: some of the features in OFBiz are not fully implemented > (or maintained), so they can be used in limited use cases (and fail > with others). > For example, billing accounts, as they are currently implemented, > are far from perfect and, in a production system, should be used > only in limited use cases; fixing/completing the billing account > processes will not be an easy task and the maintainers of the > release branch could also consider to hide the billing account > support to the users, instead of waiting for someone to complete > the implementation of them. > > Does it make sense? > > Jacopo > > > Walter Vaughan wrote: >> MINUS 42 votes!!!! >> We have *calculation* issues in the Jira issues that need to be >> either fixed or marked as closed. >> These are not features. These are places that ofBiz generates >> incorrect values, stores bad data, and does the wrong thing. >> Does anyone think that it won't create 10 times more effort to fix >> these in both a release and trunk branch? >> Feature lock TODAY. Fix/Close these issues. Branch, then resume >> the feature/framework changes... >> jira number affects patch? description >> 885 accounting no multiple item issuances from different >> sources generates only one tax adjustment >> 896 accounting no actions performed after an accepted >> payment could cause that payment record to be rolled back >> 876 order calculation yes multiple problems with editing >> orders that contain promotion items >> 870 shipping no Shipping Settings in XML don't match >> Presented Options in New Order Shipping >> 830 inventory yes problems when receiving inventory for >> which backorder exists >> 765 customers no Create New Customer fails if done after >> initial/aborted anonymous checkout >> 732 orders no passing "processorder" request can create >> an order without shipping or payment information >> 714 accounting no Adding another product to an order with >> a marketing component product causes mixups in accounting, >> manufacturing and inventory. >> 681 accounting no Wrong amount authorized for orders with >> credit card and billing account >> 578 order calculation no problems with billing account >> customer orders >> 559 order calculation no ability to add a tracking code >> or campaign to a sales order >> 482 order calculation yes Invoice generation from order >> fails if there is a percent item adjustment >> 424 order calculation no Order edit items/add item blows >> away item adjustments >> 314 order calculation no Items in Shopping cart are lost >> on login. >> 312 shipping no picklist shows incorrect quantities for >> out of stock items >> 224 order calculation no Problem with approximations if >> the ShoppingCart.basePrice has more than three decimal digits >> 223 order calculation no CartShipInfo objects are not >> properly cloned when shopping cart items are exploded. >> 74 order payment no billing account error in checkout >> Walter > |
smime.p7s (3K) |
|
The alternative is to leave the incomplete (according to Jacopo) feature there with wires sticking
out. If that's what you consider a "release", that's fine by me. I know how to "round off" some loose ends myself, so it's no bother. I don't really expect things entirely OOTB. Jonathon David E. Jones wrote: > > A feature hiding could cause a LOT of problems, and in itself be a new > "feature" to maintain... especially for something as critical as billing > accounts. > > If billing accounts were removed it would totally break a to business > type of sales cycle which OFBiz generally supports quite well (ie RFQ, > quote, order, invoice, payment). The BillingAccounts are used to > coordinate the invoicing and payments and track whether or not credit is > available for additional sales orders. > > -David > > > On Apr 18, 2007, at 7:27 AM, Jacopo Cappellato wrote: > >> Walter, >> >> apart from my previous remark on the approach to follow, I agree with >> you that it would be great to see these items fixed asap in the trunk, >> and thanks for your review. >> >> After a quick review of the issues in your list, there is a comment I >> can do: some of the features in OFBiz are not fully implemented (or >> maintained), so they can be used in limited use cases (and fail with >> others). >> For example, billing accounts, as they are currently implemented, are >> far from perfect and, in a production system, should be used only in >> limited use cases; fixing/completing the billing account processes >> will not be an easy task and the maintainers of the release branch >> could also consider to hide the billing account support to the users, >> instead of waiting for someone to complete the implementation of them. >> >> Does it make sense? >> >> Jacopo >> >> >> Walter Vaughan wrote: >>> MINUS 42 votes!!!! >>> We have *calculation* issues in the Jira issues that need to be >>> either fixed or marked as closed. >>> These are not features. These are places that ofBiz generates >>> incorrect values, stores bad data, and does the wrong thing. >>> Does anyone think that it won't create 10 times more effort to fix >>> these in both a release and trunk branch? >>> Feature lock TODAY. Fix/Close these issues. Branch, then resume the >>> feature/framework changes... >>> jira number affects patch? description >>> 885 accounting no multiple item issuances from different >>> sources generates only one tax adjustment >>> 896 accounting no actions performed after an accepted >>> payment could cause that payment record to be rolled back >>> 876 order calculation yes multiple problems with editing >>> orders that contain promotion items >>> 870 shipping no Shipping Settings in XML don't match >>> Presented Options in New Order Shipping >>> 830 inventory yes problems when receiving inventory for >>> which backorder exists >>> 765 customers no Create New Customer fails if done after >>> initial/aborted anonymous checkout >>> 732 orders no passing "processorder" request can create an >>> order without shipping or payment information >>> 714 accounting no Adding another product to an order with a >>> marketing component product causes mixups in accounting, >>> manufacturing and inventory. >>> 681 accounting no Wrong amount authorized for orders with >>> credit card and billing account >>> 578 order calculation no problems with billing account >>> customer orders >>> 559 order calculation no ability to add a tracking code or >>> campaign to a sales order >>> 482 order calculation yes Invoice generation from order >>> fails if there is a percent item adjustment >>> 424 order calculation no Order edit items/add item blows >>> away item adjustments >>> 314 order calculation no Items in Shopping cart are lost on >>> login. >>> 312 shipping no picklist shows incorrect quantities for out >>> of stock items >>> 224 order calculation no Problem with approximations if the >>> ShoppingCart.basePrice has more than three decimal digits >>> 223 order calculation no CartShipInfo objects are not >>> properly cloned when shopping cart items are exploded. >>> 74 order payment no billing account error in checkout >>> Walter >> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |