Avoiding slowdown in trunk development (was: gnulib strftime imported into Emacs)

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 23:08:44 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> On 01/31/2011 08:05 PM, Eli Zaretskii wrote:
> 
> > I understand that this is because you don't actually build on your
> > feature branches, but instead merge onto the trunk first, and build
> > there.
> 
> No, I never build on my copy of the trunk.  I use that copy only to
> install already-tested new source code and immediately commit the
> result to Savannah

In that case, I really don't see how waiting for corresponding Windows
changes could slow you down.  A couple of possible workflows come to
mind:

 . Continue working in the same branch where you developed the
   changeset that is waiting.  When the Windows changes are ready, you
   can merge onto the trunk only that one changeset (using the -r
   option to "bzr merge").

 . Start a new branch for further work, based on either the trunk or
   the branch you just worked on, and whose latest changeset awaits
   the commit.  Branching is pretty cheap with bzr, because it's a
   local operation.  Last time I tried, it took about 20 sec on a
   reasonably fast GNU/Linux system, plus a couple of minutes to
   bootstrap the tree (you could avoid the bootstrap by just copying
   over all the *.elc files).  With this workflow, you will be able to
   merge each feature independently.

These are just the simplest possibilities (and I'm quite sure you are
already familiar with them).

So I really don't see what worries you.

The only real delay is in delivering the new feature to the trunk.
But I don't see how a couple of days of delay could possibly be of any
practical importance; do you?  There are many other projects with more
disciplined commit policies, where e.g. a commit requires an a-priori
approval; surely it doesn't mean those projects are unduly slowing
down their development?

> if that commit fails due to a nearly-simultaneous
> trunk commit by someone else, I typically just revert my copy of the
> trunk and start over.

I hope by "revert" you meant "bzr up", not "bzr revert".  The short
time window for the kind of race condition that could happen in this
situation will rarely cause changes in parts that are related to your
changes.  So reverting is not needed.  Bazaar (as other dVCSs) is very
good at merging, so conflicts are rare even if the changes overlap.

> The Windows port should not require mainline developers
> to spend significant chunks of their time.

How is this different from spending time on fixing problems of other
proprietary platforms, e.g. Solaris?

Please also note that in Emacs, most of the development happens in
platform-independent and device-independent parts, so people who track
the development trunk are not used to breakage that affects a single
platform.  That is one reason for the annoyances you saw last week.

> Anyway, as I've said before, I'm hoping that this is
> not necessary, and that we don't need to use separate branches
> to support Microsoft ports.

Same here.