Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 14:19:48 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> On 01/31/11 03:06, Eli Zaretskii wrote:
> 
> > I'm talking only about changes that are known in advance to break
> > some platform, and for which you are not providing the corresponding
> > changes as part of the changeset.  I'm asking whether it would be
> > possible to talk a short while before committing such changes,
> 
> Sure, I can send out some email when I'm coding up changes.  It should
> be easy to do that, as part of normal development.

Thanks, this should make things easier and more smooth.

> > when you already have your feature branch ready to merge onto the trunk.
> 
> This part sounds too strict, though.  Normally it takes quite some
> time to prepare the change precisely for the trunk.

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.  IMO, that's an inefficient workflow when using a dVCS.  If you
would build your feature branches, then merging onto the trunk would
be an easier job, that basically boils down to a short test of your
changes with the latest mainline code.  That testing does not need to
repeat all the elaborate tests you did on a branch, because a few days
worth of Emacs development cannot change the code too much.

> > If the change needs non-trivial corresponding changes in the Windows
> > build process, I might indeed ask to wait a few days.
> 
> This part worries me.  Mainline Emacs development shouldn't be held
> back because of a lack of resources to port it to Windows.

You could port it yourself.  Most of the changes are trivially ported,
especially for someone who knows such a great deal about gnulib.

> > Emacs 24 is still very far from a release, so why is it important to
> > commit changes urgently (except changes that fix bad bugs)?
> 
> Because we want it as easy as possible to make improvements to Emacs.

As easy as possible, but no easier.

> > We are using a dVCS now, so waiting with a changeset should not slow
> > down others, nor even you yourself, with any further development.
> 
> Yes it would, because it would cost more integration and testing time,
> for mainline developers.  Also it would slow us down in making further
> improvements that depend on earlier improvements.

Using feature branches better should all but eliminate this
difficulty.

> The burden of integration and testing for Windows platforms should
> be on the people contributing to the Windows ports, not on mainline
> developers.

I never requested anything else.  But a bit of cooperative spirit
won't hurt anyone.