Maintainers list

Maintainers list

[DJ Delorie]

Given the popularity of gcc and the growing number of contributors,
it's no surprise that people have been complaining about patches going
unreviewed for long periods of time ("falling through the cracks").  I
understand that gcc is maintained by volunteers who are busy doing gcc
work in addition to their regular life.  It would be best if
contributors "championed" their own patches, but the available
information is minimal about how to do that.

To address this, I have some ideas:

* The MAINTAINERS file lists all the maintainers, but it's often
  unclear which ones to contact if you can't get a response from the
  mailing list.  Especially when a "various maintainer" is also a
  "blanket write privs" maintainer and is thus likely to be very busy.
  Would it be worthwhile to put the effort into expanding the
  MAINTAINERS file to assist contributors, perhaps by giving explicit
  file names instead of "foo port" or "bar feature"?  Or maybe a
  statement at the top like "If you are reading this because you're
  submitting a patch..."?

* Perhaps a maintainer is different from a point of contact.  Just
  because A is a maintainer for a file, doesn't mean that A is the
  right person to bug about reviewing patches.

* Perhaps each file should be tagged with an origin and a list of
  maintainers, in the order you should try to contact them?  Something
  like this kind of comment:

	/* %% Master: gnu.gcc.org:/cvs/egcs %% */
	/* %% Maintainer: J Random Hacker <jrandom@hacker.net> %% */
	/* %% Maintainer: John Doe <johndoe@aol.com> %% */

  However, this may cause excessive personal email, which would be bad.

* The contribute.html page should include an example email to use when
  following up to an unreviewed patch.  Having a standard subject
  (example: "Follow-up to unreviewed patch") would make it easy for
  maintainers to catch it the second time around.  It should also
  suggest subject line conventions for the initial patch, like
  "[patch] file.c file.h" so that the maintainers can quickly
  determine if they should respond to it.

I had also thought of a program that monitored gcc-patches and tried
to guess when a patch went unreviewed, but the technical hurdles are
pretty high for something like that.

Comments?  Other ideas?

Re: Maintainers list

[Martin v. Loewis]

> To address this, I have some ideas:

I'm not on the steering committee, so feel free to ignore my comments
:-)

>   Would it be worthwhile to put the effort into expanding the
>   MAINTAINERS file to assist contributors, perhaps by giving explicit
>   file names instead of "foo port" or "bar feature"?

I doubt it. Who's going to maintain that list?

>   Or maybe a statement at the top like "If you are reading this
>   because you're submitting a patch..."?

I'm not sure how much it would help - why don't you submit a patch in
this respect ?-)

> * Perhaps a maintainer is different from a point of contact.  Just
>   because A is a maintainer for a file, doesn't mean that A is the
>   right person to bug about reviewing patches.

Maintainers, in general, are people that the committee and other
contributors trust to do the right thing. So they are typically the
people who'd be in charge of reviewing the patches, also.

> * Perhaps each file should be tagged with an origin and a list of
>   maintainers, in the order you should try to contact them?

I don't think this would help solving the problem at hand. That list
would also get frequently outdated.

> * The contribute.html page should include an example email to use when
>   following up to an unreviewed patch.  Having a standard subject
>   (example: "Follow-up to unreviewed patch") would make it easy for
>   maintainers to catch it the second time around.  It should also
>   suggest subject line conventions for the initial patch, like
>   "[patch] file.c file.h" so that the maintainers can quickly
>   determine if they should respond to it.

That is a good idea. In fact, maintainers of C++ have been requiring
for a long time that C++ patches have a subject of [C++] (or the
like). Adding "[patch]" is not necessary - patches should be sent to
gcc-patches@gcc.gnu.org (and nothing else should be sent there, except
for discussion of a patch).

> I had also thought of a program that monitored gcc-patches and tried
> to guess when a patch went unreviewed, but the technical hurdles are
> pretty high for something like that.

The easiest thing might be to identify the ChangeLog entry in the
patch, and check whether the entry appears in any of the ChangeLogs.
A program checking that could also check whether patches being
contributed indeed do provide a ChangeLog entry.

> Comments?  Other ideas?

Well, I'd say having more volunteers to review patches, and make
recommendations to maintainers may help - if they a good at that, they
may become maintainers themselves one day :-)

There is a number of standard things to look for in a patch. Like I'm
looking for presence of source code, and reproducability, in bug
reports, these people would look for presence of ChangeLogs, presence
of test cases, conformance to the style guides, fixing only a single
problem, and they would test the patches whether they do what they
promise to do.

Regards,
Martin

Re: Maintainers list

[Theodore Papadopoulo]

May be the idea is totally silly, but...

Why not having a CVS patch directory in which all pending patches not 
yet reviewed would be stored with some explicit name conventions...

The main advantages are:

	- that not everyone will need to sort out patches 
          incoming on the patch mailing-list and track the multiple 
          versions of a given patch when testing or reviewing. 

	- A standard repository structure will help applying and 
          testing patches.

	- Relaxed rules could be adopted for write access to this
	  directory (or CVS repo). By this I do not mean that everyone
          would be allowed to add patches but an augmented list of
          people (people that without being maintainers are 
          knowledgeable enough to classify the patch, judge about its
          importance,...). Ideally, once a patch goes in the submitter
	  should be allowed to replace it by new versions but I do 
          not know how this could be done.

	- A systematic way to store and retrieve the patch that have 
          been applied.

Drawbacks:

	- cvs might not be the best tool to deal with the properties 
          of such a directory (typically files do not have a huge 
          lifetime and many modifications).

	- This might reduce the testing of stock gcc if people are 
          starting testing (and keeping installed) patches before
          they have been reviewed by someone knowledgeable.
  
	- needs people to organize the directory. The feasibility of 
          feeding the directory from the patch mailing list (in some 
          not yet sorted category) is not so clear (unless very strict
          rules for patch submission are applied). This would be nice
          to avoid having patches falling through the cracks...
          Maybe some good submission scripts may help ?

	- Certainly many others since no one has proposed this yet...


	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: Maintainers list

[Gerald Pfeifer]

On Fri, 9 Jun 2000, Theodore Papadopoulo wrote:
> Why not having a CVS patch directory in which all pending patches not 
> yet reviewed would be stored with some explicit name conventions...

The FreeBSD project uses GNATS to maintain such patches.

See
  http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18648
  http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18564
  http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18877
for examples.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Maintainers list

[Nathan Sidwell]

DJ Delorie wrote:

> I had also thought of a program that monitored gcc-patches and tried
> to guess when a patch went unreviewed, but the technical hurdles are
> pretty high for something like that.

What we need is a (better) patch tracking system, can GNATS be bashed
into shape to do that?

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Unofficial Patch file for 1 May to 30 May 2000 now available

[Tim Josling]

In the spirit of solving something rather than just complaining,
I have created a patch/diff file that bridges the gap between
2000-05-01 and 2000-05-30. Currently there is a patch for
2000-05-08 to 2000-05-30 but none for 2000-05-01 to 2000-05-08.
And there is no full dump for 2000-05-08, so this is the next
best thing.

I stress this is unauthorised, unapproved, and "entirely without
scriptural authority". But I hope it is useful to someone. It is
about 1.5 MB in size which is about 1/10 of the size of the full
download. It is a .tgz file containing a diff file constructed
according to the usual conventions for these files.

Whoever looks after the snapshot download directories should feel
entirely free to put this file or a pointer to it in the
appropriate directory.

http://www.geocities.com/timjosling/egcs-20000501-20000530_diff.tgz

Now, download those new bugs/features,

Tim Josling

Re: Maintainers list

[Martin v. Loewis]

> The FreeBSD project uses GNATS to maintain such patches.
> 
> See
>   http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18648
>   http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18564
>   http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18877
> for examples.

Seems like a good idea. From a technical point of view, it would not
be difficult to add a patches category, or to declare the
change-request category as the one keeping track of, well, change
requests.

Of course, before that is set up, maintainers should indicate whether
they'd prefer such a procedure to the current one. It requires
additional maintainance steps (e.g. to close a PR after the patch was
installed), which is currently done informally by the maintainer
responding with a "Done" message. 

On the plus side, it is easy to tell what the pending patches are, and
maintainers don't have to organize that in their mail folders,
instead, they can trust that GNATS keeps track.

Regards,
Martin

Re: Maintainers list

[Philipp Thomas]

* Martin v. Loewis (martin@loewis.home.cs.tu-berlin.de) [20000609 12:01]:

> Of course, before that is set up, maintainers should indicate whether
> they'd prefer such a procedure to the current one.

At least I would be all for it.

> On the plus side, it is easy to tell what the pending patches are, and
> maintainers don't have to organize that in their mail folders,
> instead, they can trust that GNATS keeps track.

Yepp, and everybody would be able to browse that info and look for
themselves. 

BTW, would it be possible to have GNATS bug the responsible maintainer if a
patch hasn't been reviewed for a given period?

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

Re: Maintainers list

[Martin v. Loewis]

> BTW, would it be possible to have GNATS bug the responsible maintainer if a
> patch hasn't been reviewed for a given period?

I believe so, yes: GNATS will send reminders repeatedly if configured so.

Regards,
Martin

Re: Maintainers list

[Gerald Pfeifer]

On Thu, 8 Jun 2000, DJ Delorie wrote:
> * The contribute.html page should include an example email to use when
>   following up to an unreviewed patch.  Having a standard subject
>   (example: "Follow-up to unreviewed patch") would make it easy for
>   maintainers to catch it the second time around.  It should also
>   suggest subject line conventions for the initial patch, like
>   "[patch] file.c file.h" so that the maintainers can quickly
>   determine if they should respond to it.

Having some conventions for Subjects makes sense. Many of us already do
something like that, but informally, like tagging C++ patches or listing
filenames affected by the patch.

I don't think we should be too strict, but some recommendations might
be useful. Concrete suggestions, anyone?

> I had also thought of a program that monitored gcc-patches and tried
> to guess when a patch went unreviewed, but the technical hurdles are
> pretty high for something like that.

If you can get this to work (more or less), a reminder bot might make
sense, though it certainly is not trivial to implement that.

I also made a suggestion in http://gcc.gnu.org/ml/gcc/2000-07/msg00783.html
but have not received any response yet. :-(

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/