This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Getting patches applied
- From: Petr Baudis <pasky at suse dot cz>
- To: Roland McGrath <roland at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sun, 22 Aug 2010 21:47:01 +0200
- Subject: Re: Getting patches applied
Hi!
On Thu, Aug 19, 2010 at 03:45:34PM -0700, Roland McGrath wrote:
> Both of the particular things you cited are areas on which Ulrich is
> authoritative and other maintainers would not commit nontrivial changes
> without his review.
I see. My personal opinion is that maybe we have a scaling problem;
plenty of bugs get into the codebase even with Ulrich reviewing
everything and I think being more liberal about committed changes would
do good (as long as they touch no exported API, of course).
However, I do not want to seek change for the sake of change itself
and I will be happy to try it out your way and see how it works out.
> As things stand today, the best bet is to do a fresh concise posting here
> so Ulrich can look at it. If you just refer to bugzilla pages and long
> trails of history, it's easy for people not to bother looking and let it
> sit until it gets dropped on the floor again. If your posting has a clear
> and concise statement of the problem that stands on its own, then someone
> authoritative can get to the issue quickly and chances are better. If one
> or more system builders are already using a patch and it is working well,
> then mentioning that might make a difference.
>
> Another thing you might do is start pushing one or many pasky/* branches
> of things you think are fit to merge. (Fewer branches are easier to
> juggle, but more distinct branches increases the chances that any
> particular topic branch will be approved and merged.)
I have made an initial push to branches:
* pasky/fixes-overdue (conservative pick of patches long in bugzilla)
* pasky/fixes (full queue of all fixes I have gathered)
The branches will rebase to be always based on latest upstream and
have one commit per fix.
I will send pull requests regularly with full log entries - these
should do fine for concise descriptions I hope, and I also include
bugzilla numbers.
If others want their fixes to be tracked by me too, please just let me
know about them if I won't pick them up on my own.
--
Petr "Pasky" Baudis
The true meaning of life is to plant a tree under whose shade
you will never sit.