Handling of Glibc Patches

Handling of Glibc Patches

[Andreas Jaeger]

During the last time I've noticed that different people came up with
patches for the same problem - often even with the same patches.

As a small example, I made this morning a tiny patch to integrate the
two new constants from Linux 2.3.29 - only to find out when I'm ready
with my email that Ulrich has just checked in these patches.  I don't
think there was a way to avoid this specific problem at all [1] - but
often there's more time between the submission of the patches and
duplication of work could have been reduced.

The same patches generated by different developers implies a
unnecessary duplication of work.  Since the group of core developers
is quite small and most of us don't have that much spare time, we
should reduce this overlap as much as possible.

What can be done to improve the handling of patches?

One solution would be to create a libc-patches list where everybody
would send patches to (similar to gcc-patches).  This way we could see
what others have done, comment on the patches and don't duplicate the
work.;-)

What do you think?

Andreas

Footnotes: 
[1]  Since we worked simultaneously on it.
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

Re: Handling of Glibc Patches

[Mark Kettenis]

   From: Andreas Jaeger <aj@suse.de>
   Date: 24 Nov 1999 10:23:08 +0100

   What can be done to improve the handling of patches?

   One solution would be to create a libc-patches list where everybody
   would send patches to (similar to gcc-patches).  This way we could see
   what others have done, comment on the patches and don't duplicate the
   work.;-)

I think this is a good idea, but the discussion on the patches should
still happen on libc-hacker or libc-alpha.

But still:

 * Nobody should work on larger changes (new functionality, major code
   reorganizations) without notifying the list first.

 * It's not always a bad thing that different people try to tackle the
   same problem.  If they come out with the same solution, that
   probably means that the solution is right!  If they don't come out
   with the same solution, this might indicate that some further
   investigation is necessary.

Mark

Re: Handling of Glibc Patches

[Ulrich Drepper]

Mark Kettenis <kettenis@wins.uva.nl> writes:

> I think this is a good idea, but the discussion on the patches should
> still happen on libc-hacker or libc-alpha.

I don't thing that a new list is necessary.  Simply send the patches
to libc-hacker.  All the people on this list would be on the new one
anyhow.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Handling of Glibc Patches

[Philip Blundell]

>I don't thing that a new list is necessary.  Simply send the patches
>to libc-hacker.  All the people on this list would be on the new one
>anyhow.

I agree.  The libc-hacker list is hardly high volume, a few more patches won't 
hurt.

p.