This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patchwork for glibc?


From: Ramana Radhakrishnan <ramana.gcc@googlemail.com>
Date: Fri, 14 Feb 2014 19:14:22 +0000

> What I don't like is this admin aspect for patches and reviews for
> each project - that's effectively one person doing admin stuff per
> project and I think developers doing this admin stuff regularly is
> just a waste of their time.

In practice, patchwork allows me to review and fully clasify hundreds
of patches per day for the Linux kernel networking.  I've been using
the tool every single day for years.

If you use the tool properly, it is not a time sink to classify the
patches at all.  Most of my time is spent reading the patch and the
threads of discussion attached to the patches, as it should be.

I think it is misguided to suggest that it is an improvement to have
the tool integrated somehow into the version control system and
automatically update the disposition of the patch when a commit
happens.

Rather, I think you really want to bring up the entry on the patchwork
page so you can read the whole thread of discussion, making sure you
didn't miss anything.  And then, decide to apply or not apply the
patch, and since you have the patchwork page open for that patch
already, you can re-classify it as you close the web browser window.

You can do this for groups of patches using bundles.  So one click
can update the classification of arbitrary numbers of patches.

If commits automatically make patchwork statuses update, mistakes will
happen, things will be missed, and overall things will work worse.

It is absolutely not a waste of time for someone to be doing this work
to carefully make sure each patch is considered properly, with
discussion context et al., rather than some automated process
bypassing all of this.

We maintain carefully a list of people who have commit rights, and
likewise we can carefully maintain a list of people who can admin
the glibc patchwork group.

It's going to be a massive step forward from what is happening right
now in glibc land.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]