commits to master

[Cyrille Berger Skott]

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)

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).

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"

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.

-- 
Cyrille Berger Skott