On Thursday, April 12, 2012 08:54:22 Boudewijn Rempt wrote: > On Wednesday 11 April 2012 Apr, Cyrille Berger Skott wrote: > > Hi, > > > > For me this is how it should be: commits in master are restricted to: > > > > * single commit bug fixes > > * merge from feature branches (or single commit feature, note that I > > personnaly don't encourage this practise) > > Same here -- I think this is a good rule. > > > Then the amount of reviewing for commits or merge is left at the > > discretion of the developers and maintainers. But in general, the > > closest to the library, the less trivial the patch is, the more review > > it needs (same apply for patches that touch saving and loading code). > > Yes, indeed. > > > As for merging a feature branch, it should only happen once the feature > > is release ready, ie when there is no known (serious) bug and no known > > crashes. It does not mean the feature is judge "complete", but it should > > be already usefull. For instance, if you implement spell checking, the > > desirable complete feature include highlighting of mistakes and offering > > corrections, it would be acceptable to merge after implementing > > highlighting, and then a second time after the correction UI is in > > place. > > > > This last part is what would allow to get very short beta cycle, since > > basically master would be in almost releasable state at all time. And the > > idea is that bugs are fixed as they come in (and applied to relevant > > branches), instead of this alternance of 4 months of feature coding and > > 2 months of bug fixing (also called 4 months of fun and 2 months of pain > > ;p). > > > > And then the release schedule looks like this: > > > > Week 7: Alpha release > > Week 10: Beta release, branching into "futurestable" string freeze > > Week 13: RC > > Week 16: Final release "futurestable" replaces "stable" > > I think this should be our policy :-)
With the risk of sounding like a 'useless AOL'er'[1]: +1 [1] http://www.youtube.com/watch?v=qpMvS1Q1sos _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
