On 19 November 2011 14:21, Anders Logg <l...@simula.no> wrote: > 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? >
That's fine. Garth > -- > 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
