Omitting Windows-specific parts from infrastructure changes

Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

When people make infrastructure and low-level changes all over the
source tree, I'd appreciate if they either include the MS-Windows
specific parts in the scope of the changes, or at least tell here
explicitly that this-and-that parts were omitted for such-and-such
reasons.  Several changes installed lately did neither, which leaves
those left-out places to be discovered either by chance or by bug
reports.  That mode of operation makes very little sense to me.

Thanks in advance.

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

As a general rule any change that I make omits changes to MS-Windows code.  I 
don't understand MS-Windows well enough to change its code reliably, and I have 
no easy way to test any changes that I would make.  Typically my changes do not 
introduce problems on the MS-Windows side, but if I notice potential problems 
there I give Eli a heads-up before installing the change, so that he can address 
the problems.  This has been our longstanding practice.

The recent Qnil == 0 change was a substantial low-level change that shook out 
some unexpected glitches in both MS-Windows and non-MS-Windows code.  Had I seen 
the MS-Windows glitches in advance I would have given Eli a specific heads-up 
about them, but I didn't see them.  Sorry about that.  I'm also sorry for the 
non-MS-Windows glitches, of course.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Fri, 16 Jan 2015 19:39:12 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> As a general rule any change that I make omits changes to MS-Windows
> code.

Sorry, that's not good enough.  I'm sure when you do such changes, you
grep (or otherwise search) the whole tree for relevant places, so you
always know whether MS-Windows code is potentially involved.  All I'm
asking is that you provide that information when it is relevant.

> I don't understand MS-Windows well enough to change its code
> reliably, and I have no easy way to test any changes that I would
> make.

A change of strcpy/strcat to use stpcpy doesn't require any
understanding of Windows specific code.  A change in Makefile.in to
use AM_V_* stuff doesn't require any Windows knowledge, either.  I
could give more examples, but I think these two are clear enough.

Like I said: I'm okay with your refraining from making the changes,
what I'm asking is to say that you spotted those places, with specific
file names pointed out, but didn't make any changes there.  Like I do
when a display-related change needs changes in xterm.c or xfns.c or
nsfns.m which I cannot test and sometimes cannot even compile.

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

Eli Zaretskii wrote:
> I'm sure when you do such changes, you
> grep (or otherwise search) the whole tree for relevant places

No, I hardly ever do that.  For example, I don't look at the Lisp code if I'm 
changing some aspect of the C code that shouldn't affect Lisp.  And in instances 
like the strcpy/stpcpy change, where the changes' effects don't bleed into the 
MS-Windows port, I don't look at the MS-Windows code.  In this sense the 
MS-Windows code is like the OS X code, or like any other part of the Emacs 
source code for that matter.

Ideally, the MS-Windows code would be a completely separate module, so that 
changes in the Emacs core would not affect it and non-MS-Windows developers 
would never need to worry about it.  We're obviously not there, as we have too 
many dependencies between the core and the MS-Windows code, one of the symptoms 
of which is too many "#ifdef WINDOWSNT" directives sprinkled throught the core 
modules.  In some aspects, though, we do have good separation, and this kind of 
separation should be encouraged, and it's good when developers can take 
advantage of it.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Sun, 18 Jan 2015 10:09:43 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > I'm sure when you do such changes, you
> > grep (or otherwise search) the whole tree for relevant places
> 
> No, I hardly ever do that.

Then please start doing that from now on.  That is, unless you are
working on a change that specifically affects only X or only Posix
platforms.

> Ideally, the MS-Windows code would be a completely separate module

That's a completely separate issue, unrelated to the issue at hand.

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

>>> I'm sure when you do such changes, you
>>> grep (or otherwise search) the whole tree for relevant places
>>
>> No, I hardly ever do that.
>
> Then please start doing that from now on.

I'd rather not.  If someone else wants to search other modules for opportunities 
to make similar changes, that's obviously fine, but's it's not at all necessary. 
  Work like this should belong to the modules in question; among other things, 
it is more efficiently done by people who care about and are expert in those 
modules.

>> Ideally, the MS-Windows code would be a completely separate module
>
> That's a completely separate issue, unrelated to the issue at hand.

No, the issues are related.  If the modules in question were completely 
independent, this thread would not have come up.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Sun, 18 Jan 2015 11:25:38 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> >>> I'm sure when you do such changes, you
> >>> grep (or otherwise search) the whole tree for relevant places
> >>
> >> No, I hardly ever do that.
> >
> > Then please start doing that from now on.
> 
> I'd rather not.  If someone else wants to search other modules for opportunities 
> to make similar changes, that's obviously fine, but's it's not at all necessary. 
>   Work like this should belong to the modules in question; among other things, 
> it is more efficiently done by people who care about and are expert in those 
> modules.

But I didn't ask you to do the actual work, just point out the files
where changes similar to what you did might be needed.  That's all.
Without that, people who do want to do the work are basically unable
to do it, without repeating what you already did anyway, and on top of
that they need to guess what methods you used to identify the places
where changes are needed -- something that isn't documented in the
change logs.

IOW, basically the request is to post a short note about things you
know anyway.  The only extra work is composing the message itself.

> >> Ideally, the MS-Windows code would be a completely separate module
> >
> > That's a completely separate issue, unrelated to the issue at hand.
> 
> No, the issues are related.  If the modules in question were completely 
> independent, this thread would not have come up.

It would have come up anyway, since the same infrastructure is used
everywhere.  It's the same C language, the same object system, the
same Makefile's and build system, etc.

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

Eli Zaretskii wrote:
> IOW, basically the request is to post a short note about things you
> know anyway.  The only extra work is composing the message itself.

But as I mentioned, I don't know these things, as I don't look at the MS-Windows 
code when I make changes like that.  It's not reasonable to expect developers to 
search all modules every time they make a change that could conceivably be 
modified and/or adapted and/or adjusted to some other module.  We already have 
too much to do, and this extra bureaucracy's cost would outweigh its benefit.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Sun, 18 Jan 2015 12:34:01 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
>     IOW, basically the request is to post a short note about things you
>     know anyway.  The only extra work is composing the message itself.
> 
> But as I mentioned, I don't know these things, as I don't look at the MS-Windows code when I make changes like that. It's not reasonable to expect developers to search all modules every time they make a change that could conceivably be modified and/or adapted and/or adjusted to some other module. We already have too much to do, and this extra bureaucracy's cost would outweigh its benefit.

It's a small overhead, yes.

What's the alternative, though?  Doing nothing means leaving the parts
you side-stepped to bit-rot and generate bug reports, which is a
maintenance burden we'd like to avoid, so it's clearly not acceptable.

Leaving it to others to discover the places that were omitted, without
any guidance as to how to identify them is too error-prone, so will
again cause bugs.

Another alternative would be for you to describe how you searched for
relevant places in the modules you did review and change -- either by
presenting the scripts and/or commands you used, or as a plain-text
description of the course of actions needed to identify those places.
I think this would be more work for you, but if you prefer it that
way, it's probably okay, too.

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

Eli Zaretskii wrote:
> Doing nothing means leaving the parts
> you side-stepped to bit-rot and generate bug reports,

Nothing is rotting here, as the code is working.  No bug reports have been 
generated because of this longstanding practice.  As the benefits of the 
proposed change to the practice do not appear to exceed the costs, I'd rather 
leave things be.

> Leaving it to others to discover the places that were omitted, without
> any guidance as to how to identify them is too error-prone

No special guidance is needed, as the search heuristics are obvious.  For 
example, if the change involves replacing strcat with stpcpy, look at all uses 
of strcat in the modules you're interested in.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Mon, 19 Jan 2015 10:00:55 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > Doing nothing means leaving the parts
> > you side-stepped to bit-rot and generate bug reports,
> 
> Nothing is rotting here, as the code is working.

It is working because I cleaned it up.  It didn't work before that,
and in some places didn't use the new infrastructure, but the old
one.  Leaving this as it is will eventually produce maintenance
headaches we are better without.

> No bug reports have been generated because of this longstanding
> practice.  As the benefits of the proposed change to the practice do
> not appear to exceed the costs, I'd rather leave things be.

The costs are minuscule: just a short notice posted here.  So I really
don't understand why you refuse to honor such a simple and reasonable
request for some minimal help to your fellow developers.  Can you
explain?

> > Leaving it to others to discover the places that were omitted, without
> > any guidance as to how to identify them is too error-prone
> 
> No special guidance is needed, as the search heuristics are obvious.  For 
> example, if the change involves replacing strcat with stpcpy, look at all uses 
> of strcat in the modules you're interested in.

All I'm asking is to post a short note to that effect when such
changes are done in the future.  Without that, what needs to be done
is not easily discoverable, since we don't usually document that in
our logs.  In contrast, someone who does this change should have no
difficulty either describing the search heuristics or even pointing
out the places where the changes need to be followed-up.

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

Eli Zaretskii wrote:
> It is working because I cleaned it up.  It didn't work before that

No, the code already worked for the patches we're talking about, e.g., replacing 
strcat with stpcpy.  And it still works, in the places where the MS-Windows code 
still uses strcat instead of stpcpy.

> The costs are minuscule: just a short notice posted here.

The costs would be more than that, as I'd need to examine code that I don't look 
at now, and I'd have to save notes about the examination somewhere, and keep 
track of these notes during the time period between searching and installing the 
fix, which is often weeks.  I have dozens of variants of the GNU Emacs 
development sources and can't be expected to remember how each was derived, so 
all this work product would have to be maintained somehow.  This would add 
nontrivial bureaucracy to the maintenance of mainline code, with only a trivial 
benefit to non-mainline maintenance.  It's not worth it.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Mon, 19 Jan 2015 14:14:28 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
>     It is working because I cleaned it up.  It didn't work before that
> 
> No, the code already worked for the patches we're talking about, e.g., replacing strcat with stpcpy. And it still works, in the places where the MS-Windows code still uses strcat instead of stpcpy.

Beg your pardon, but how do you know this?  Since you said you don't
look into the Windows modules and don't understand their code, you
cannot possibly know whether it works/worked or not.

>     The costs are minuscule: just a short notice posted here.
> 
> The costs would be more than that, as I'd need to examine code that I don't look at now

You already said you didn't want to do that, and I already said you
don't have to.  So this is not required.

> and I'd have to save notes about the examination somewhere, and keep track of these notes during the time period between searching and installing the fix, which is often weeks.

Not required: just post those notes once when you first do the
examination, and don't bother updating them, if that's a burden.

> This would add nontrivial bureaucracy to the maintenance of mainline code, with only a trivial benefit to non-mainline maintenance.

I assure you, the benefit is not trivial for me.  If it were, I
wouldn't have bothered starting all this uneasy discussion.

> It's not worth it.

It is worth it for me.  Please help me maintain the parts of Emacs in
which you have no interest.  Keeping those parts in good shape is a
prerequisite for my participation in the project, so it is of utmost
importance to me, if not to you.  (I think it's also of importance to
the project as a whole, but we seem to have quite different views of
the project's good, so you'll probably disagree.  However, I hope
others will agree with me.)

TIA

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

On 01/20/2015 08:32 AM, Eli Zaretskii wrote:
>> it still works, in the places where the MS-Windows code still uses strcat instead of stpcpy.
> Beg your pardon, but how do you know this?

Because I made an extra effort to check, as part of following up this 
conversation.  Normally I don't bother since there's no point, but since 
you raised the issue I took the time to double-check something that was 
already obvious.  This is not something I regularly do, or want to do.

> just post those notes once when you first do the examination

I don't have any notes to post.  I don't write notes for this sort of thing.

Honestly, I don't see why this is such a big deal.  Anyone who's curious 
about uses of strcat in the MS-Windows code can easily search the code 
for instances of the string "strcat".  No special advice or notes are 
needed.  And if nobody bothers to do the search, that's fine too.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Tue, 20 Jan 2015 13:28:10 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
>         it still works, in the places where the MS-Windows code still uses strcat 
>         instead of stpcpy.
> 
>     Beg your pardon, but how do you know this?
> 
> Because I made an extra effort to check, as part of following up this conversation.

Which changeset did you check?  There were quite a few of them.  It
could be that some of them didn't break anything, but some certainly
did.

And leaving portions of Emacs out of the set of files that is kept in
good shape is bad for maintenance, so even changes that don't break
need to be made everywhere, at least as a goal.

>     just post those notes once when you first do the examination
>
> I don't have any notes to post.  I don't write notes for this sort of thing.

"Notes" is just a word.  I'm asking you to post the information that
can be used by someone else to find the places which you omitted from
the scope of your changes.  That information is certainly available to
you when you are working on the changeset, so just publish it whenever
it's the most convenient moment for you.

> Honestly, I don't see why this is such a big deal. Anyone who's curious about uses of strcat in the MS-Windows code can easily search the code for instances of the string "strcat".

_After_ we know that the changeset had to deal with strcat following
strcpy, yes, it's a simple thing to find those places.  But that's
exactly what I'm asking you to publish -- the description of what to
look for, either as plain text or as a script that does the job, if
you used such a script and have it available.

Without this information, one has to somehow glean it by
reverse-engineering your commits.  Which is not easy, because they are
complex and quite often include changes not directly related to the
main issue of the changeset.  So this process is error-prone and takes
precious time.

Take your suggested changes in bug#19634: I think you left out at
least one place in w32 files, but I cannot be sure without knowing
calls to which functions should be converted to use CALLN.  I need to
read a 1800-odd line patch to try to understand that, whereas it would
have taken you no more than a single sentence to describe that
clearly.

Honestly, I don't see why it's such a big deal to make this job much
easier by simply publishing the information that is clear to you and
at your fingertips when you work on the changeset.  It is a very small
overhead for you, and a huge benefit for me.  So I'm asking you to
please humor me with this small favor.

> And if nobody bothers to do the search, that's fine too.

That might be your personal goal, but please don't punish your fellow
developers that happen to disagree with you on that.  We all have our
personal preferences, but we shouldn't go after fellow developers
whose preferences are different.  If we do, what kind of team are we?

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

Eli Zaretskii wrote:
>>          it still works, in the places where the MS-Windows code still uses strcat
>>          instead of stpcpy.
>>
>>      Beg your pardon, but how do you know this?
>>
>> Because I made an extra effort to check, as part of following up this conversation.
>
> Which changeset did you check?

I looked at the the version of the master current as of when I wrote the email.

> _After_ we know that the changeset had to deal with strcat following
> strcpy, yes, it's a simple thing to find those places.

Great, then you can do this simple thing, whenever you find it convenient.  It's 
not urgent, and it can be omitted entirely for changes like this.

> We all have our
> personal preferences, but we shouldn't go after fellow developers
> whose preferences are different.

Exactly, and for several days you have been going after me, asking me to do 
nonessential drudgework to help polish up the MS-Windows code.  I prefer not to.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Wed, 21 Jan 2015 09:32:09 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >>          it still works, in the places where the MS-Windows code still uses strcat
> >>          instead of stpcpy.
> >>
> >>      Beg your pardon, but how do you know this?
> >>
> >> Because I made an extra effort to check, as part of following up this conversation.
> >
> > Which changeset did you check?
> 
> I looked at the the version of the master current as of when I wrote the email.

All of it?  And how do you know it's not broken?  Did you run Emacs on
Windows?  Did you try all those features affected by the changes I was
talking about?

> > _After_ we know that the changeset had to deal with strcat following
> > strcpy, yes, it's a simple thing to find those places.
> 
> Great, then you can do this simple thing, whenever you find it
> convenient.

How can I do that without knowing what to do?  "This simple thing"
needs to be defined, and I'm asking you to help me define it.  Then I
can pick up where you prefer to leave off.

> It's not urgent, and it can be omitted entirely for changes like
> this.

No, it cannot be omitted.  It should be your job, as part of the
changes you make.  I could simply object to your changes that do a
partial job, or revert them.  Instead, I agree to do that work for
you, and all I'm asking in return is a little help, insignificant for
you, but one that will save me a non-trivial amount of time cleaning
up after you.

> > We all have our
> > personal preferences, but we shouldn't go after fellow developers
> > whose preferences are different.
> 
> Exactly, and for several days you have been going after me, asking me to do 
> nonessential drudgework to help polish up the MS-Windows code.  I prefer not to.

You could have said yes after the first request.  Then this discussion
would have been long over.

I'm sorry, but "I prefer not to" is unacceptable in this case.  Please
find a way to provide the minimal help that I'm asking for.

Re: Omitting Windows-specific parts from infrastructure changes

[Paul Eggert]

On 01/21/2015 09:55 AM, Eli Zaretskii wrote:

> I could simply object to your changes that do a
> partial job, or revert them.

Wow, is this really a threat to block or revert changes to the Emacs 
mainline code, as leverage to force people to do unnecessary drudgework 
to help polish up the MS-Windows code?

This is starting to get ridiculous.  Let's drop the discussion, as we're 
not making any progress (quite the reverse, I'm afraid).

Re: Omitting Windows-specific parts from infrastructure changes

[Dmitry Gutov]

On 01/21/2015 09:39 PM, Paul Eggert wrote:

> Wow, is this really a threat to block or revert changes to the Emacs
> mainline code, as leverage to force people to do unnecessary drudgework

Regardless of the outcome of this discussion, I hope everyone realizes 
that the presence and adequate functioning of Emacs ports to proprietary 
operating systems is beneficial to GNU/Linux users as well, since it 
increases the size of the ecosystem.

For instance, the maintainer of what currently seems to be the best hope 
for a Java editing environment (malabar-mode) uses Windows.

Yours truly has spent quite a bit of time on Windows as well. Had Emacs 
port not been available then, I'd probably have ended up not using it at 
all in the end.

> to help polish up the MS-Windows code?

It seems to me that the goal is to help keep it up-to-date.

(Sorry for butting in).

Re: Omitting Windows-specific parts from infrastructure changes

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 01/21/2015 09:55 AM, Eli Zaretskii wrote:
>
>> I could simply object to your changes that do a
>> partial job, or revert them.
>
> Wow, is this really a threat to block or revert changes to the Emacs
> mainline code, as leverage to force people to do unnecessary
> drudgework to help polish up the MS-Windows code?

I don't see a threat here.  When a change in master breaks functionality
for a number of people, the change is reverted as a rule in the projects
that I am an active member of.  Once the problems have been sorted out,
the change may be recommitted.

A half-finished change does not just affect the person who ends up
fixing the change but everybody else who is working on the platforms
broken by a change.  Not everyone is in a position to fix every change,
and there is no point in having a dozen people frantically working on
the same fix.

Emacs is developed with a distributed version control system so working
on private changes is perfectly possible without affecting the common
public repository.

Where a change requires involving multiple platform maintainers, it is
easily possible to first propose/provide the change in a branch where
the respective platform developers able to test or cater for a change
can prepare such changes without affecting the usability of the master
branch for other developers.

> This is starting to get ridiculous.

It struck me as ridiculous for quite longer than you it would seem, but
then I would guess for quite different reasons.

> Let's drop the discussion, as we're not making any progress (quite the
> reverse, I'm afraid).

While it does not appear that you've changed the stance of either of you
two in any way, at least others became aware of the issue and of your
inability to come to an agreement.  That makes it more likely that
others will try contributing to a resolution in case the problem
reappears.

But since resentment tends to be higher when people not directly
affected try effecting a change, that tends to have a worse chance for
deescalating the situation than if those directly affected can find a
way of cooperating themselves.

-- 
David Kastrup

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Wed, 21 Jan 2015 11:39:34 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 01/21/2015 09:55 AM, Eli Zaretskii wrote:
> 
> > I could simply object to your changes that do a
> > partial job, or revert them.
> 
> Wow, is this really a threat to block or revert changes to the Emacs 
> mainline code, as leverage to force people to do unnecessary drudgework 
> to help polish up the MS-Windows code?

No.  It's a reminder that infrastructure changes should be done across
the board, or not at all.  A developer who does such changes cannot
unilaterally decide that some parts of the code will be exempted.  It
is okay to ask others to help with platforms to which you don't have
access.  I offered you my help with Emacs code specific to MS-Windows.
That offer still stands.

IOW, what you call "polish up MS-Windows code" is actually part of the
job of developing Emacs.  You cannot unilaterally decide to change
this policy.

> This is starting to get ridiculous.  Let's drop the discussion, as we're 
> not making any progress (quite the reverse, I'm afraid).

I already suggested several ways to resolve this.  Feel free to make
your own suggestions, provided that the result will be that such
changes are done everywhere, without unduly punishing your fellow
developers who offer you help to do parts of your job.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> Date: Wed, 21 Jan 2015 22:07:02 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> For instance, the maintainer of what currently seems to be the best hope 
> for a Java editing environment (malabar-mode) uses Windows.
> 
> Yours truly has spent quite a bit of time on Windows as well. Had Emacs 
> port not been available then, I'd probably have ended up not using it at 
> all in the end.

My main development machine runs MS-Windows.  So if I'm to continue my
participation in Emacs development, the Windows build must be in good
shape.

On top of that, for better or worse, people who use Emacs on Windows
happen to look up to me for fixing whatever problems happen there.
Therefore, gratuitous additional difficulties in keeping the Windows
build in good shape, such as those caused by Paul's selective changes,
simply prevent me from doing more work in platform-independent parts
of the code, like working on bugs and features not specific to
MS-Windows.  It's a net loss to everyone, including Paul.

> > to help polish up the MS-Windows code?
> 
> It seems to me that the goal is to help keep it up-to-date.

We want to keep all the ports for modern platforms up-to-date.

> (Sorry for butting in).

Nothing to be sorry for.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 21 Jan 2015 21:08:20 +0100
> 
> Emacs is developed with a distributed version control system so working
> on private changes is perfectly possible without affecting the common
> public repository.
> 
> Where a change requires involving multiple platform maintainers, it is
> easily possible to first propose/provide the change in a branch where
> the respective platform developers able to test or cater for a change
> can prepare such changes without affecting the usability of the master
> branch for other developers.

That's certainly a possibility.  But it, too, assumes some minimal
level of cooperation between the platform maintainers.  At the very
least, the idea and perhaps also the details of the change should be
published.  It makes no sense to ask others to guess how to find which
places on their platforms need change from large diffs.

> > Let's drop the discussion, as we're not making any progress (quite the
> > reverse, I'm afraid).
> 
> While it does not appear that you've changed the stance of either of you
> two in any way, at least others became aware of the issue and of your
> inability to come to an agreement.  That makes it more likely that
> others will try contributing to a resolution in case the problem
> reappears.

I hope so, because I've exhausted all the ideas for compromise I had,
and they all have been rejected.

Re: Omitting Windows-specific parts from infrastructure changes

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 21 Jan 2015 11:39:34 -0800
>> From: Paul Eggert <eggert@cs.ucla.edu>
>
>> This is starting to get ridiculous.  Let's drop the discussion, as we're 
>> not making any progress (quite the reverse, I'm afraid).
>
> I already suggested several ways to resolve this.  Feel free to make
> your own suggestions, provided that the result will be that such
> changes are done everywhere, without unduly punishing your fellow
> developers who offer you help to do parts of your job.

It's not his job.  We are rather talking about how to enable different
people interested in different things to continue working on code in the
same Emacs repository.  As far as I know, it is nobody's _job_ to do so
currently (Gerd Möllmann once had a job working on the Emacs 21 display
engine if I remember correctly).  Neither the parts he did are his
"job", nor the parts he did not do.

In a project driven by volunteers it makes good sense when people invest
those kinds of work that otherwise would cause a much larger workload.
Sometimes this does not work, like when basically the best-suited person
for pretty much any task is the same person.  In that case, there is
some sense in others doing part of the work in spite of them being less
efficient at it, simply because there are limits to what a single person
can do.

However, in a project as large and diverse as Emacs, when we indeed have
the situation "if I had to tell anybody what I am doing, I would not
have enough time to do it", this is basically an unmaintainable
situation where indeed it might be more prudent from refraining to a
change where not even the resources for properly implementing it
throughout the code base _or_ communicating the necessary changes are
available.

-- 
David Kastrup

Re: Omitting Windows-specific parts from infrastructure changes

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Wed, 21 Jan 2015 21:08:20 +0100
>> 
>> Emacs is developed with a distributed version control system so working
>> on private changes is perfectly possible without affecting the common
>> public repository.
>> 
>> Where a change requires involving multiple platform maintainers, it is
>> easily possible to first propose/provide the change in a branch where
>> the respective platform developers able to test or cater for a change
>> can prepare such changes without affecting the usability of the master
>> branch for other developers.
>
> That's certainly a possibility.  But it, too, assumes some minimal
> level of cooperation between the platform maintainers.  At the very
> least, the idea and perhaps also the details of the change should be
> published.  It makes no sense to ask others to guess how to find which
> places on their platforms need change from large diffs.

I disagree here since those others will know the way around their
platform code better than someone catering for a different platform.

I would not myself go pointing out which stuff should be changed in the
Windows code in order to parallel some GNU/Linux specific code changes
I submit.

But that does not mean that a contributor should refrain from describing
what he had to do on _his_ platform (with a high-level description
rather than one tied into the platform-specific code) to accommodate the
changes, and what functionality will likely be affected similarly on
other platforms.

-- 
David Kastrup

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Wed, 21 Jan 2015 21:49:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Wed, 21 Jan 2015 11:39:34 -0800
> >> From: Paul Eggert <eggert@cs.ucla.edu>
> >
> >> This is starting to get ridiculous.  Let's drop the discussion, as we're 
> >> not making any progress (quite the reverse, I'm afraid).
> >
> > I already suggested several ways to resolve this.  Feel free to make
> > your own suggestions, provided that the result will be that such
> > changes are done everywhere, without unduly punishing your fellow
> > developers who offer you help to do parts of your job.
> 
> It's not his job.  We are rather talking about how to enable different
> people interested in different things to continue working on code in the
> same Emacs repository.

No, we are talking about making changes in infrastructure used by all
platforms.  Once someone decides to make such changes, making
good-faith effort to do that in all parts of Emacs is part of the job.
It could be done either by actually making those changes all over, or
by asking platform maintainers to do the parts related to their
platforms.  In the latter case, the platform maintainers should have
enough information about the proposed change to be able to do their
parts without investing too much time and effort where the initiator
can help them avoid that.

For example, in the recently discussed changeset that uses CALLN for
some C-level calls to Lisp APIs, the information that should be passed
to platform maintainers is how to identify the offending calls.  This
information is clear to the person who initiated the change and it's
possible to describe it in a sentence or two.  I have hard time
understanding how this kind of requirement could be described as
impossible or hard to comply.

Re: Omitting Windows-specific parts from infrastructure changes

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 21 Jan 2015 21:57:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> >> Date: Wed, 21 Jan 2015 21:08:20 +0100
> >> 
> >> Emacs is developed with a distributed version control system so working
> >> on private changes is perfectly possible without affecting the common
> >> public repository.
> >> 
> >> Where a change requires involving multiple platform maintainers, it is
> >> easily possible to first propose/provide the change in a branch where
> >> the respective platform developers able to test or cater for a change
> >> can prepare such changes without affecting the usability of the master
> >> branch for other developers.
> >
> > That's certainly a possibility.  But it, too, assumes some minimal
> > level of cooperation between the platform maintainers.  At the very
> > least, the idea and perhaps also the details of the change should be
> > published.  It makes no sense to ask others to guess how to find which
> > places on their platforms need change from large diffs.
> 
> I disagree here since those others will know the way around their
> platform code better than someone catering for a different platform.

Once the information about what should be changed is given, yes.  And
that is all that was requested.

> I would not myself go pointing out which stuff should be changed in the
> Windows code in order to parallel some GNU/Linux specific code changes
> I submit.

No one requested that.

> But that does not mean that a contributor should refrain from describing
> what he had to do on _his_ platform (with a high-level description
> rather than one tied into the platform-specific code) to accommodate the
> changes, and what functionality will likely be affected similarly on
> other platforms.

Exactly, this is the only request.

Re: Omitting Windows-specific parts from infrastructure changes

[Stefan Monnier]

I don't want to get into this discussion, but in case people wonder
where I stand, I fully agree with Eli's position below.


        Stefan


> No, we are talking about making changes in infrastructure used by all
> platforms.  Once someone decides to make such changes, making
> good-faith effort to do that in all parts of Emacs is part of the job.
> It could be done either by actually making those changes all over, or
> by asking platform maintainers to do the parts related to their
> platforms.  In the latter case, the platform maintainers should have
> enough information about the proposed change to be able to do their
> parts without investing too much time and effort where the initiator
> can help them avoid that.

> For example, in the recently discussed changeset that uses CALLN for
> some C-level calls to Lisp APIs, the information that should be passed
> to platform maintainers is how to identify the offending calls.  This
> information is clear to the person who initiated the change and it's
> possible to describe it in a sentence or two.  I have hard time
> understanding how this kind of requirement could be described as
> impossible or hard to comply.