dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?

--
Anders