dolfin team mailing list archive

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

On 19 November 2011 14:21, Anders Logg <logg@xxxxxxxxx> wrote:
> On Sat, Nov 19, 2011 at 01:52:23PM +0000, Garth N. Wells wrote:
>> On 19 November 2011 12:30, Anders Logg <logg@xxxxxxxxx> wrote:
>> > On Sat, Nov 19, 2011 at 12:12:39PM +0000, Garth N. Wells wrote:
>> >> 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.
>> >
>> > 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
>