On Sat, Nov 19, 2011 at 01:52:23PM +0000, Garth N. Wells wrote: > On 19 November 2011 12:30, Anders Logg <l...@simula.no> wrote: > > On Sat, Nov 19, 2011 at 12:12:39PM +0000, Garth N. Wells wrote: > >> On 19 November 2011 12:03, Anders Logg <l...@simula.no> wrote: > >> > On Sat, Nov 19, 2011 at 11:33:25AM +0000, Garth N. Wells wrote: > >> >> On 19 November 2011 11:29, Anders Logg <l...@simula.no> wrote: > >> >> > On Sat, Nov 19, 2011 at 11:25:17AM +0000, Garth N. Wells wrote: > >> >> >> On 19 November 2011 11:19, Anders Logg <l...@simula.no> wrote: > >> >> >> > On Sat, Nov 19, 2011 at 11:09:18AM -0000, nore...@launchpad.net > >> >> >> > wrote: > >> >> >> >> Merge authors: > >> >> >> >> Anders Logg (logg) > >> >> >> >> ------------------------------------------------------------ > >> >> >> >> revno: 6447 [merge] > >> >> >> >> committer: Garth N. Wells <gn...@cam.ac.uk> > >> >> >> >> 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. > > > > I think keeping the buildbot green should be top priority, especially > > now when the top priority, at least for me, is 1.0. > > > > We're talking about merging *from* the 1.0 branch into trunk. This > doesn't affect the 1.0 buildbots.
(My point is that my top priority at the moment is 1.0, merging into trunk is secondary until after the release, for me.) We both agree that we should merge often. The question is when, before or after the 1.0 buildbot is green. Since the merge is from 1.0 to trunk, the policy could be to merge directly since 1.0 is presumably more stable than trunk, and testing should always be done on a personal buildbot before merging into 1.0: 0. test locally (optional) 1. test on personal buildbot 2. merge into 1.0 if green 2. merge into trunk at the same time ok? -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
