commits to master

[Boudewijn Rempt]

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