all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Omitting Windows-specific parts from infrastructure changes
Date: Wed, 21 Jan 2015 17:48:38 +0200	[thread overview]
Message-ID: <83d268w2w9.fsf@gnu.org> (raw)
In-Reply-To: <54BEC86A.7060605@cs.ucla.edu>

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



  reply	other threads:[~2015-01-21 15:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16  9:54 Omitting Windows-specific parts from infrastructure changes Eli Zaretskii
2015-01-17  3:39 ` Paul Eggert
2015-01-17  8:34   ` Eli Zaretskii
2015-01-18 18:09     ` Paul Eggert
2015-01-18 18:23       ` Eli Zaretskii
2015-01-18 19:25         ` Paul Eggert
2015-01-18 19:50           ` Eli Zaretskii
2015-01-18 20:34             ` Paul Eggert
2015-01-19 16:03               ` Eli Zaretskii
2015-01-19 18:00                 ` Paul Eggert
2015-01-19 18:32                   ` Eli Zaretskii
2015-01-19 22:14                     ` Paul Eggert
2015-01-20 16:32                       ` Eli Zaretskii
2015-01-20 21:28                         ` Paul Eggert
2015-01-21 15:48                           ` Eli Zaretskii [this message]
2015-01-21 17:32                             ` Paul Eggert
2015-01-21 17:55                               ` Eli Zaretskii
2015-01-21 19:39                                 ` Paul Eggert
2015-01-21 20:07                                   ` Dmitry Gutov
2015-01-21 20:38                                     ` Eli Zaretskii
2015-01-21 20:08                                   ` David Kastrup
2015-01-21 20:49                                     ` Eli Zaretskii
2015-01-21 20:57                                       ` David Kastrup
2015-01-22  3:53                                         ` Eli Zaretskii
2015-01-21 20:30                                   ` Eli Zaretskii
2015-01-21 20:49                                     ` David Kastrup
2015-01-22  3:51                                       ` Eli Zaretskii
2015-01-22 14:20                                         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83d268w2w9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.