dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Nov 19, 2011 at 11:33:25AM +0000, Garth N. Wells wrote:
> On 19 November 2011 11:29, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Sat, Nov 19, 2011 at 11:25:17AM +0000, Garth N. Wells wrote:
> >> On 19 November 2011 11:19, Anders Logg <logg@xxxxxxxxx> wrote:
> >> > On Sat, Nov 19, 2011 at 11:09:18AM -0000, noreply@xxxxxxxxxxxxx wrote:
> >> >> Merge authors:
> >> >>   Anders Logg (logg)
> >> >> ------------------------------------------------------------
> >> >> revno: 6447 [merge]
> >> >> committer: Garth N. Wells <gnw20@xxxxxxxxx>
> >> >> 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.

--
Anders