Re: gnulib strftime imported into Emacs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 31 Jan 2011 00:02:21 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 01/30/2011 08:00 PM, Eli Zaretskii wrote:
> 
> > Could we please talk before making such disruptive changes in the
> > future?
> 
> We did talk; for example,
> <http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01025.html>.
> I thought this was enough, but apparently I was mistaken.

That was a general heads-up (thanks!).  I'm talking about actually
saying something like "I'm about to commit changes that will break the
Windows build."

> I worry that this would mean that every time I want to make a
> nontrivial change to a makefile, I would have to run the exact change
> by you first.

I didn't ask to run every nontrivial change by me.  Inadvertent
breakage is a fact of life, and cannot be helped.  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, when you already have your
feature branch ready to merge onto the trunk.

> And, as you say, you don't have much free time, and can't be
> expected to respond quickly; it might need to wait until the next
> weekend

I usually respond to email within a few hours.  In extreme rare cases,
it could take a day.  So the response will be fast.  If the change
needs non-trivial corresponding changes in the Windows build process,
I might indeed ask to wait a few days.

And it's not just me personally.  There are others on this list who
could (and hopefully would) pick up the gauntlet and provide the fix
as fast as possible.

> That wouldn't be a good recipe for development; it would slow things
> down too much on the trunk.

Emacs 24 is still very far from a release, so why is it important to
commit changes urgently (except changes that fix bad bugs)?  We are
using a dVCS now, so waiting with a changeset should not slow down
others, nor even you yourself, with any further development.  Am I
missing something?

> If this turns into a continuing problem

It wasn't until now.  I don't see why it has to become a continuing
problem.

> perhaps it would be better to establish a branch for
> Microsoft-related platforms, and to merge changes from the trunk
> into that branch whenever you have time.  People could then do
> Microsoft builds from that branch.

I'm talking only about Windows (and any other radically different
platforms whose builds you cannot test).  MS-DOS is not related to
this.  No MS-DOS users except myself are tracking the trunk
development, so the MS-DOS build can stay broken for as much as I can
afford.

I think a separate branch for Windows is unjustified, but if we are
talking separate branches, an alternative would be to establish a
separate branch for synchronizing with gnulib, and only merge it to
the trunk when all major supported platforms are known to build on
that branch.  (FWIW, that's what I did before merging the bidi
support.)  Judging by the last week's experience, the number of people
who get annoyed by not being able to build the latest trunk on Windows
is not negligible (I myself generally build only on weekends), so a
non-urgent change that will certainly break it could be first
committed to a public branch.

> > It also means that Tom will have to wait for yet another week with his
> > threading related changes
> 
> Sorry, I don't get the connection.  Tom can't put in his threading
> related changes until Emacs builds on Microsoft platforms?

The threading changes are certain to break any platform where Tom is
unable to test, and in fact the error messages during the build are
the main device to find the way of making those changes work on any
given platform (IIUC).  So 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.  Tom asked to give him a
notice when the Windows build becomes usable again, which I did two
days ago.  Now I must again ask Tom to wait, for the same reason.