dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Feb 09, 2011 at 06:02:00PM +0000, Garth N. Wells wrote:
>
>
> On 09/02/11 17:18, Anders Logg wrote:
> > On Wed, Feb 09, 2011 at 08:44:52AM -0800, Johan Hake wrote:
> >> On Wednesday February 9 2011 04:56:09 Marie E. Rognes wrote:
> >>> On 02/09/2011 01:55 PM, Garth N. Wells wrote:
> >>>> I think that this is overkill. I don't mind the buildbot breaking (by
> >>>> accident) as long as it's fixed quickly. What causes problems are major
> >>>> changes that result in extended red periods, and during which other
> >>>> breakages are unknowingly introduced. This type of development should
> >>>> take place in a personal branch.
> >>>>
> >>>> I'm happy with minor changes, incremental development, bug fixes, etc,
> >>>> to be added by developers directly to main (with the expectation that
> >>>> tests have been run locally). The less merging the better.
> >>>
> >>> Agree!
> >>
> >> +
> >>
> >> If the real reason for the more complicated push policy was that you do not
> >> like what other developer introduce ;), we could try to use the Blueprint
> >> and/or email list more!
> >
> > I like the new "complicated" push policy (which is not so complicated,
> > really) since it allows me to push the stuff I do quickly (often
> > without testing) and not worrying about breaking anything.
> >
>
> I don't see how the simple or complicated approaches affect this - we're
> all free to break personal branches.

What I mean is that I can always break my local copy on my laptop, but
having a semi-official personal branch on Launchpad connected to a
buildbot has advantages:

1. automatic testing by a buildbot

2. pushing is a simple way of announcing that I'm working on a
   new feature (interesting for those who care about that
   particular feature)

I think there's a tendency (at least for me personally) to push things
too early in wanting to announce that things are happening ("look, I'm
working on fixing this bug", "look, I'm adding this cool feature"),
which leads to repeated breaking of the main branch. With the new
merge structure, we can get both: early push + stable main.

I guess my main point here is that "bzr push" is a simple and
efficient way to communicate (with other developers). Those that care
can read the commit message, others can ignore.

--
Anders