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
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
