dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

I think that this is overkill. I don't mind the buildbot breaking (by
accident) as long as it's fixed quickly. What causes problems are major
changes that result in extended red periods, and during which other
breakages are unknowingly introduced. This type of development should
take place in a personal branch.

I'm happy with minor changes, incremental development, bug fixes, etc,
to be added by developers directly to main (with the expectation that
tests have been run locally). The less merging the better.

Garth

On 09/02/11 12:16, Anders Logg wrote:
> Here's a suggestion for how to handle merges with personal
> maintainer branches:
> 
> A. If personal branch is green and changes are "uncontroversial" (bug
> fixes, improvements, etc):
> 
>   1. create merge request on Launchpad
>   2. merge
> 
> B. If personal branch is green and one can suspect the merge may lead
> to discussions (new features, new designs, etc):
> 
>   1. create merge request on Launchpad
>   2. wait for a while (1/2 - 1 day?)
>   3. merge if there are no objections
> 
> 
> Step (1) is good since it signals that a merge is about to
> happen. Other maintainers should then look at the proposed changes and
> object before the branch is merged.
> 
> Another thing I've been considering is if perhaps it would be a good
> idea to make Johannes responsible for keeping the main branch green.
> The strategy would be very simple:
> 
>   while True:
> 
>     if green:
>       idle
>     elsif red:
>       revert latest merge
> 
> Would that work?
> 
> --
> Anders
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp