bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] libposix: Add _HEADERS primaries to posix modules.


From: Jim Meyering
Subject: Re: [PATCH] libposix: Add _HEADERS primaries to posix modules.
Date: Sun, 06 Feb 2011 18:59:04 +0100

Bruce Korb wrote:
> Hi Bruno, et al.  I have merged the patch:
> http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00044.html
> into the sources, yielding the patch below.  Barring final testing
> problems or complaints, I am hoping to push later today.
> Thank you.  Regards, Bruce

Hi Bruce,

Giving an ultimatum like that with a mere half-day's notice is not how
we do things in gnulib.  It might be seen as inconsiderate or even
impertinent.  Once you post a patch for review, you should plan to
wait for ACKs from all involved, especially for a change affecting so
many modules.

As for who is involved, it is anyone listed as "maintainer" of a module
or script that is affected, and it is a good idea to Cc: them individually,
in case that helps alert them.

If after a few days, you are still missing ACKs, you may want to ping
individuals, just in case they haven't seen the original or haven't had
time to review your work.  If you get desperate, you can always repost,
telling any who have not responded that you interpret their silence as
acceptance, and giving them, say, one day more.

I'm thinking especially of Bruno, since I did not see a reply from
him accepting your proposed change.  Though I suppose it's possible
that he replied to you off-list.  However, that is unlikely, since...

Looking at it now, I see one part of your change for which most of us
would have requested an adjustment.  It introduces indentation via
TABs in gnulib-tool.  Everywhere else in that file, it uses spaces:

                 -e 's,lib%_LTLIBRARIES,lib_LTLIBRARIES,g' \
+               -e "$sed_transform_libgnu_a" \


We are leery of sweeping changes like these, and as you know, this one
has already caused trouble in at least two client projects: m4 and emacs.
We usually go to great pains to avoid requiring client projects to make
such changes.  In the future, you can help forestall objections or delays
by ensuring that two or three projects do indeed bootstrap when using
your proposed changes.

Jim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]