dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 19 November 2011 12:03, Anders Logg <logg@xxxxxxxxx> wrote:
> 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.
>

Effective development is the number one priority. Buildbots are tool
in this. Just keeping a buildbot green is not the top priority.

Garth


> --
> Anders
>