* Maintainers list @ 2000-06-08 12:03 DJ Delorie 2000-06-08 15:32 ` Martin v. Loewis ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: DJ Delorie @ 2000-06-08 12:03 UTC (permalink / raw) To: gcc 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-08 12:03 Maintainers list DJ Delorie @ 2000-06-08 15:32 ` Martin v. Loewis 2000-06-09 2:05 ` Theodore Papadopoulo 2000-06-09 2:28 ` Nathan Sidwell 2000-07-27 15:23 ` Gerald Pfeifer 2 siblings, 1 reply; 10+ messages in thread From: Martin v. Loewis @ 2000-06-08 15:32 UTC (permalink / raw) To: dj; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-08 15:32 ` Martin v. Loewis @ 2000-06-09 2:05 ` Theodore Papadopoulo 2000-06-09 2:18 ` Gerald Pfeifer 0 siblings, 1 reply; 10+ messages in thread From: Theodore Papadopoulo @ 2000-06-09 2:05 UTC (permalink / raw) To: Martin v. Loewis; +Cc: dj, gcc 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 -------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-09 2:05 ` Theodore Papadopoulo @ 2000-06-09 2:18 ` Gerald Pfeifer 2000-06-09 2:43 ` Unofficial Patch file for 1 May to 30 May 2000 now available Tim Josling 2000-06-09 3:00 ` Maintainers list Martin v. Loewis 0 siblings, 2 replies; 10+ messages in thread From: Gerald Pfeifer @ 2000-06-09 2:18 UTC (permalink / raw) To: Theodore Papadopoulo; +Cc: Martin v. Loewis, dj, gcc 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/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Unofficial Patch file for 1 May to 30 May 2000 now available 2000-06-09 2:18 ` Gerald Pfeifer @ 2000-06-09 2:43 ` Tim Josling 2000-06-09 3:00 ` Maintainers list Martin v. Loewis 1 sibling, 0 replies; 10+ messages in thread From: Tim Josling @ 2000-06-09 2:43 UTC (permalink / raw) To: egcs; +Cc: gcc, gcc-patches 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-09 2:18 ` Gerald Pfeifer 2000-06-09 2:43 ` Unofficial Patch file for 1 May to 30 May 2000 now available Tim Josling @ 2000-06-09 3:00 ` Martin v. Loewis 2000-06-12 14:28 ` Philipp Thomas 1 sibling, 1 reply; 10+ messages in thread From: Martin v. Loewis @ 2000-06-09 3:00 UTC (permalink / raw) To: pfeifer; +Cc: Theodore.Papadopoulo, dj, gcc > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-09 3:00 ` Maintainers list Martin v. Loewis @ 2000-06-12 14:28 ` Philipp Thomas 2000-06-18 5:34 ` Martin v. Loewis 0 siblings, 1 reply; 10+ messages in thread From: Philipp Thomas @ 2000-06-12 14:28 UTC (permalink / raw) To: Martin v. Loewis; +Cc: pfeifer, Theodore.Papadopoulo, dj, gcc * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-12 14:28 ` Philipp Thomas @ 2000-06-18 5:34 ` Martin v. Loewis 0 siblings, 0 replies; 10+ messages in thread From: Martin v. Loewis @ 2000-06-18 5:34 UTC (permalink / raw) To: pthomas; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-08 12:03 Maintainers list DJ Delorie 2000-06-08 15:32 ` Martin v. Loewis @ 2000-06-09 2:28 ` Nathan Sidwell 2000-07-27 15:23 ` Gerald Pfeifer 2 siblings, 0 replies; 10+ messages in thread From: Nathan Sidwell @ 2000-06-09 2:28 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Maintainers list 2000-06-08 12:03 Maintainers list DJ Delorie 2000-06-08 15:32 ` Martin v. Loewis 2000-06-09 2:28 ` Nathan Sidwell @ 2000-07-27 15:23 ` Gerald Pfeifer 2 siblings, 0 replies; 10+ messages in thread From: Gerald Pfeifer @ 2000-07-27 15:23 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2000-07-27 15:23 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-06-08 12:03 Maintainers list DJ Delorie 2000-06-08 15:32 ` Martin v. Loewis 2000-06-09 2:05 ` Theodore Papadopoulo 2000-06-09 2:18 ` Gerald Pfeifer 2000-06-09 2:43 ` Unofficial Patch file for 1 May to 30 May 2000 now available Tim Josling 2000-06-09 3:00 ` Maintainers list Martin v. Loewis 2000-06-12 14:28 ` Philipp Thomas 2000-06-18 5:34 ` Martin v. Loewis 2000-06-09 2:28 ` Nathan Sidwell 2000-07-27 15:23 ` Gerald Pfeifer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).