Bug 23094

Summary:	The PR system has no way to let committers know that a PR includes commitable code
Product:	Base System	Reporter:	mwm
Component:	misc	Assignee:	dd <dd>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	5.0-CURRENT
Hardware:	Any
OS:	Any

Description mwm 2000-11-25 20:20:01 UTC

It seems that PR's that include source - patches to fix the problem,
new documentation, new code - can sit in the PR queue for months on
end. While this is understandable for PRs that require debugging, a PR
that just needs to be audited and committed should either be commited
or rejected in fairly short order.

Fix: 

Adding some kind of "contains committable material" indicator to the
PR would allow committers to easily find - and deal with - PRs where
the user has provided an immediate contribution, as opposed to just a
bug report. Maybe a one-line "Fix" field that has options like
"bug-report; suggestion; tested patch; new code; new docs".
How-To-Repeat: 
Try submitting PRs and tracking how many get dealt with less than a
month, vs. how many get ignored for the same period of time. My
numbers have > 50% being ignored, and a fair percentage of the rest
drawing a comment or two, and *then* sitting unresolved.

Comment 1 billf 2000-11-25 20:24:00 UTC

On Sat, Nov 25, 2000 at 08:13:22PM -0000, mwm@mired.org wrote:

> >Category:       misc
> >Synopsis:       The PR system has no way to let committers know that a PR includes commitable code

typically, one uses [PATCH] at the beginning of "synopsis" to indicate
that a patch is in the PR.

-- 
Bill Fumerola - security yahoo         / Yahoo! inc.
              - fumerola@yahoo-inc.com / billf@FreeBSD.org

Comment 2 mwm 2000-11-25 20:26:02 UTC

Bill Fumerola <billf@mu.org> types:
> On Sat, Nov 25, 2000 at 08:13:22PM -0000, mwm@mired.org wrote:
> > >Category:       misc
> > >Synopsis:       The PR system has no way to let committers know that a PR includes commitable code
> 
> typically, one uses [PATCH] at the beginning of "synopsis" to indicate
> that a patch is in the PR.

Is this documented anywhere? What about man pages, FAQ submission
(though those are the exceptions to this problem), and new ports?

	<mike

--
Mike Meyer					http://www.mired.org/home/mwm/
Freelance WWW/Unix/FreeBSD consultant,		email for rates.

Comment 3 mwm 2000-11-25 21:07:29 UTC

Mike Meyer <mwm@mired.org> types:
> Bill Fumerola <billf@mu.org> types:
> > On Sat, Nov 25, 2000 at 08:13:22PM -0000, mwm@mired.org wrote:
> > > >Category:       misc
> > > >Synopsis:       The PR system has no way to let committers know that a PR includes commitable code
> > typically, one uses [PATCH] at the beginning of "synopsis" to indicate
> > that a patch is in the PR.
> Is this documented anywhere? What about man pages, FAQ submission
> (though those are the exceptions to this problem), and new ports?

In thinking about it, documenting that in the block of text at the top
of the pr page would certainly solve the problem.

	<mike

--
Mike Meyer					http://www.mired.org/home/mwm/
Freelance WWW/Unix/FreeBSD consultant,		email for rates.

Comment 4 dd freebsd_committer

2001-06-01 02:58:07 UTC

Responsible Changed
From-To: freebsd-bugs->dd

I'll document this somewhere.  Of course, if you (the originator) would like 
to suggest a place or even supply a patch, it would be most appreciated :-)

Comment 5 Peter Avalos 2001-07-21 12:14:23 UTC

I'm not an expert at sgml, but these changes should take care of any
confusion/frustration for submitting patches.

Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml,v
retrieving revision 1.456
diff -u -r1.456 chapter.sgml
--- chapter.sgml	2001/07/19 12:58:52	1.456
+++ chapter.sgml	2001/07/21 11:02:19
@@ -445,7 +445,8 @@
 	report it using the &man.send-pr.1; program or its <ulink
 	  url="http://www.FreeBSD.org/send-pr.html">WEB-based
 	  equivalent</ulink>.  Try to fill-in each field of the bug report.
-	Unless they exceed 65KB, include any patches directly in the report.
+	Unless they exceed 65KB, include any patches directly in the report,
+	and put <literal>"[PATCH]"</literal> in the synopsis.
 	When including patches, <emphasis>do not</emphasis> use cut-and-paste
 	because cut-and-paste turns tabs into spaces and makes them unusable.
 	Consider compressing patches and using &man.uuencode.1; if they exceed
@@ -522,8 +523,9 @@
 	<emphasis>Do not</emphasis> just send the diffs to the &a.hackers; or
 	they will get lost! We greatly appreciate your submission (this is a
 	volunteer project!); because we are busy, we may not be able to
-	address it immediately, but it will remain in the pr database until we
-	do.</para>
+	address it immediately, but it will remain in the PR database until we
+	do.  Indicate your submission by including <literal>"[PATCH]"</literal>
+	in the synopsis of the report.</para>
 
       <indexterm>
         <primary><command>uuencode</command></primary>

Comment 6 dima 2001-07-22 16:53:59 UTC

<pavalos@theshell.com> writes:
> Index: chapter.sgml
> ===================================================================
> RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml,
> v
> retrieving revision 1.456
> diff -u -r1.456 chapter.sgml
> --- chapter.sgml	2001/07/19 12:58:52	1.456
> +++ chapter.sgml	2001/07/21 11:02:19
> @@ -445,7 +445,8 @@
>  	report it using the &man.send-pr.1; program or its <ulink
>  	  url="http://www.FreeBSD.org/send-pr.html">WEB-based
>  	  equivalent</ulink>.  Try to fill-in each field of the bug report.
> -	Unless they exceed 65KB, include any patches directly in the report.
> +	Unless they exceed 65KB, include any patches directly in the report,
> +	and put <literal>"[PATCH]"</literal> in the synopsis.

Just <literal>[PATCH]</literal> should suffice (no quotes).

Also, it'd be nice if whatever mentions [PATCH] mentioned that this
should be used for patches which are suitable to be applied to the
repository.  There are some PRs labeled [PATCH] where the patch is
something like a sample program, or a way to reproduce the bug.  I.e.,
[PATCH] means "patch that could be applied", not "there is a patch
somewhere in this PR".

Thanks.

Comment 7 Peter Avalos 2001-07-26 19:30:23 UTC

It's not super robust, but how's this:

Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml,v
retrieving revision 1.458
diff -u -r1.458 chapter.sgml
--- chapter.sgml	2001/07/23 22:51:24	1.458
+++ chapter.sgml	2001/07/26 18:24:02
@@ -446,6 +446,8 @@
 	  url="http://www.FreeBSD.org/send-pr.html">WEB-based
 	  equivalent</ulink>.  Try to fill-in each field of the bug report.
 	Unless they exceed 65KB, include any patches directly in the report.
+	If the patch is suitable to be applied to the source tree put
+	<literal>[PATCH]</literal> in the synopsis of the report.
 	When including patches, <emphasis>do not</emphasis> use cut-and-paste
 	because cut-and-paste turns tabs into spaces and makes them unusable.
 	Consider compressing patches and using &man.uuencode.1; if they exceed
@@ -522,8 +524,9 @@
 	<emphasis>Do not</emphasis> just send the diffs to the &a.hackers; or
 	they will get lost! We greatly appreciate your submission (this is a
 	volunteer project!); because we are busy, we may not be able to
-	address it immediately, but it will remain in the pr database until we
-	do.</para>
+	address it immediately, but it will remain in the PR database until we
+	do.  Indicate your submission by including <literal>[PATCH]</literal>
+	in the synopsis of the report.</para>
 
       <indexterm>
         <primary><command>uuencode</command></primary>

Comment 8 dd freebsd_committer

2001-08-11 21:16:05 UTC

State Changed
From-To: open->closed

The handbook now mentions [PATCH]