On Fri, Feb 29, 2008 at 10:23 AM, Nicolas Lalevée < [EMAIL PROTECTED]> wrote:
> Le jeudi 28 février 2008, Xavier Hanin a écrit : > > Hi, > > > > Ivy 2.0 beta 2 being around the corner, I've reviewed some of the > current > > open issues in JIRA. I've marked all open bugs to be fixed in 2.0, as I > > would like to make 2.0 final as stable and clean as possible. I even > think > > that fixing bugs should be our main focus now toward 2.0 final. The > current > > feature set is pretty good, so if we don't want to dilute too much our > > effort and the time frame for 2.0 final, I think focusing on bug fix is > a > > good option. I don't say we should stop developing features, sometimes > we > > may have some needs or specific interest in some new features. Moreover > > fixing bugs is not the most entertaining thing to do, so we'll probably > > need some rest with more interesting stuff :-). > > > > So, do you guys agree with this plan? > > +1 > > Just one note about not stopping adding features. > > I follow the Lucene community, and they have an interesting workflow for > commits. With every feature or bug fix there is a Jira issue. Then someone > do > a patch and attach it to the issue. So the patch generally get reviewed > and > commented by sevral commiters, a patch is always commited only one or two > days after it has been proposed. And in a release period, only bug fix > patchs > are commited, the feature ones wait the final release to be public. > > I don't think we should have a such complete workflow, I don't think there > are > enought active people here, not yet. But at least for new feature in a > release period I think it would be a good practice to only do patchs but > not > commit them. > > WDYT ? I'm not sure to be a big fan of this kind of process, but maybe that becomes necessary when the number of committers and the activity rate becomes too important. I personnally prefer committing things, then using the commit notifications to review someone else modifications. If something seems wrong, we can always revert it very easily. For major changes, agreeing on dev list before actually starting implementing them seems to be a good practice to avoid vetoing things. I think we haven't had any problem so far, so I guess our light process works well enough for the project. Xavier > > > Nicolas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
