Re: gnulib strftime imported into Emacs

[joakim]

Paul Eggert <address@hidden> writes:

> 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.
>
>> Ideally, Windows related changes should be committed to the
>> repository at approximately the same time as the changes for Posix
>> platforms, but that's only possible if you let me see the changes
>> _before_ they are committed, and if we coordinate the commit to happen
>> when I have time to work on that.  Is such cooperation possible?
>
> 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.  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,
> say.  That wouldn't be a good recipe for development; it would slow things
> down too much on the trunk.
>
> If this turns into 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.
>
>> 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?

Emacs doesnt seem to have a spelled out policy but the following
approach is liked by many projects:
- commits to trunk should not knowingly break compilation
- feature development occurs on branches and are merged to trunk when
apropriate

The problem with this approach for Emacs is that it is very difficult
to test all configurations, so one can't be very sure even seemingly
trivial changes wont break compilation.

I have a Hudson continuous build server for Emacs now, building a couple
of branches on Fedora 14. I intend to set up a couple of more build
slaves for different platforms. I can reasonably expect to be able to
provide slaves for a couple of gnu/linux distributions, windows, dos,
osx, and some ARM based platform.

This won't happen soonish so it won't solve short term issues. Anyway,
in the end it will be possible for a developer to be reasonably sure a
feature branch wont break trunk builds on any supported platforms when
merged.

I'm aware that this subject is somewhat sensitive and there are various
opinions how trunk should be used etc. I'm not claiming a mandate to
enforce a policy, only offering to provide a service to enable a
particular strategy that doesn't exclude others.

-- 
Joakim Verona