commits to master

[Dag]

Fredag den 6. april 2012 00:44:34 C. Boemann skrev:
> Hi
> 
> In Berlin last year we agreed that we would move to a 4 month release cycle
> and in order to do that we promised ourselves we would keep master in a
> releasable state only merging things when it was ready to be released.
> 
> I don't think we have taken that to heart yet. Master is currently broken
> (hello Dag),
Hello ;)
Got cheated by a .gitignore, and lost my internet hence the late response.
But yes, should have used a branch for this.
> and we commit stuff without review just like we always have
> (hello myself, and several others).
> 
> I think we should at the very least do the following:
> 
>  - Mandatory publishing in branch if touching cmake files, so others can
> test it before merging to master.
> 
>  - Fewer commits, on commit per feature, not one per small change.  If we
> ever want to go back bisecting it's important that the history is in as a
> complete state as possible. This doesn't mean we shouldn't split into sub
> commits, but let's try to avoid more than 2 or 3. As an example: changes
> made as result of reviews should be squashed into the main commits of the
> feature.
> 
> 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.
> 
> Now all this assuming we want to have a short 4 month release cycle. If we
> want to keep the 6 months or probably a year, then a less strict commit
> policy might work.
> 
> 
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
-- 
Mvh.
Dag Andersen