On 19 November 2011 12:03, Anders Logg <[email protected]> wrote: > On Sat, Nov 19, 2011 at 11:33:25AM +0000, Garth N. Wells wrote: >> On 19 November 2011 11:29, Anders Logg <[email protected]> wrote: >> > On Sat, Nov 19, 2011 at 11:25:17AM +0000, Garth N. Wells wrote: >> >> On 19 November 2011 11:19, Anders Logg <[email protected]> wrote: >> >> > On Sat, Nov 19, 2011 at 11:09:18AM -0000, [email protected] wrote: >> >> >> Merge authors: >> >> >> Anders Logg (logg) >> >> >> ------------------------------------------------------------ >> >> >> revno: 6447 [merge] >> >> >> committer: Garth N. Wells <[email protected]> >> >> >> branch nick: trunk >> >> >> timestamp: Sat 2011-11-19 11:06:15 +0000 >> >> >> message: >> >> >> Merge with 1.0 branch. Why doesn't the 1.0 committer do this? >> >> > >> >> > Because it hasn't been tested yet. Shouldn't a merge wait until the >> >> > buildbot is green? >> >> > >> >> >> >> Just run the tests, and buy a new computer if it's too slow. Not >> >> merging leaves others to clean up conflicts. >> > >> > I'm actually thinking of buying a new computer, but I still think it >> > makes sense for the buildbot (not just local tests) to be green for >> > one branch before it is merged into another. >> > >> >> Not when there is extended period between merges. This makes more work >> (resolving the merge, which is error prone) than fixing a builbot >> failure. > > I'm still not sure what is the best option. If our number one priority > is to keep the buildbots green, it seems that one should check that > one is green before pushing to the other. >
Effective development is the number one priority. Buildbots are tool in this. Just keeping a buildbot green is not the top priority. Garth > -- > Anders > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
