Hi, I think it's a great idea. Also long lasting feature branches should not exist. Features must be split into smaller merges to the master. This makes integration easier. This prevents "day before" CR1 mega merges (with huge amount of conflicts). After CR1 has been branched, there should be decent testing period.
This all can be achived by split features into smallest marketable features. -jari On Fri, Jun 24, 2011 at 7:49 AM, Geoffrey De Smet <ge0ffrey.s...@gmail.com> wrote: > Hi guys, > > This release (5.2.0) has been pretty horrible. > We 've lost lots of time on: > - cherry-picking commits > - testing everything again and again (and again) because the last > cherry-picked commit just changed everything again > Which results in months of delay (branch date was 28-APR and release date > was 23-JUN). > > Let's make the next release less horrible :) > I believe this organization problem is very easy to fix, by introducing this > rule: > Don't add new features after CR1 is branched (on the CR/final release > branch) > > What do you think? Do you think this is a good idea? > > -- > With kind regards, > Geoffrey De Smet > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
