This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] Use C11 _Alignas on scratch_buffer internal buffer
On 19/09/2017 22:20, Paul Eggert wrote:
> Adhemerval Zanella wrote:
>> the changes you mentioned came mostly because you pushed
>> them without much discussion
>
> From glibc's point of view I suggest thinking of Gnulib as being the "farm team". Gnulib is largely maintained by people who are drawn to it partly because it is simpler and doesn't have all the bureaucratic hassles that glibc does, so that one can fix bugs and add features more quickly and easily than one can in glibc.
>
> There are advantages to both projects' development styles of course.
>
>> I would expect, to make it easier for both glibc and gnulib, that once a patch is submitted on a maillist we finish consensus and pushed on the referred
>> project and *after* we sync with either glibc/gnulib.
>
> I doubt whether we Gnulib folks would want to have a policy of waiting for the usual days (weeks?) for a glibc review before installing a glob fix. Often we have a software release to put out, and Gnulib is supposed to help, not to slow us down. With that in mind, perhaps it's better to continue keeping the collaboration close but not lock-step, so that the goal is for glob.c etc. to be identical in both projects, but we can tolerate short periods when this is not true.
>
> That being said, there's no rush in installing into Gnulib the current set of patches that you're proposing, and it's fine to wait for you to revise it along the lines suggested before installing it into both Gnulib and glibc.
What I am proposing based on recent glob fixes is to just align a bit
more with glibc and avoid push one side changes for the shared code.
For instance, on this very change instead of push a slight modified
version, it would be more productive if you just send a message stating
your intention is to push this modified version and give us some days
to see if anyone have anything to say. If thread get stalled, I think
it safe to proceed on gnulib side and let us deal with any glibc
requirement once we plan to sync it back.
Now back to the patch topic, I think the first union version [1] should
the most suitable one and it is what I am intended to push.
[1] https://sourceware.org/ml/libc-alpha/2017-09/msg00730.html