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 :-) > > On Friday 06 Apr 2012, C. Boemann wrote: > > Now having small commits to go through when debugging a new features is > > just fine and can happen in a SUB branch. That branch is not supposed to > > be merged to master until it's totally complete and tested anyway. So when > > it's ready to go to master, we simply create a single commit out of that > > branch and commit that to master. If you want the feature branch can stay > > forever, but we shouldn't pollute the master. > > There is no real way to solve that problem if we keep using a central > repository, as we do. The linux kernel way of development is that people need > to clean the patches they submit, but they don't share a central repository > with all branches. > > Personnaly I am not a fan of history rewritting in general. But then I don't > do much actual development anymore. > > -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
