Re: gnulib strftime imported into Emacs

[Paul Eggert]

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.

> 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 develop on RHEL
5.5 x86-64, but for nontrivial changes before committing I test on
several other platforms that I have easy access to, including at least
one non-GNU platform.  I don't want to have to do that work multiple
times, as it takes far more work to prepare and test the changes
than it does to code them up.

> 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.

> 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.
There are many obstacles to improvements, and we can't remove all the
obstacles, but we should do that when it's easy, which ought to be the
case here.

The argument "it's far from a release" cuts the other way, actually.
If we were close to release, then we would be quite careful of
nontrivial changes regardless of platform, because we wouldn't have
time to try them out.  But now, when it *is* far from a release, it's
a good time to make this kind of change.  And we don't want to slow
that process down unnecessarily.

> 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.  The burden of
integration and testing for Windows platforms should be on the people
contributing to the Windows ports, not on mainline developers.

> I don't see why it has to become a continuing problem.

I hope not too.

> I asked Tom to postpone his commit until the Windows build is
> working again.  Otherwise, it would be very hard to know how to fix
> the threading changes on Windows when there are two or more possible
> reasons for error messages.

If it's easier to test Windows builds with half of Tom's changes
first, then the Windows developers can do that.  This may make it a
bit harder on the Windows developers temporarily, but it's not that
hard: that is what version control is for.  However, if the difficulty
in doing the port to Windows is substantially slowing down Tom's
changes to Emacs proper, then there's something wrong with the overall
process, and we should fix that.  Tom shouldn't have to be waiting for
Windows developers to port his stuff.