Bug 80681
| Summary: | articles/problem-reports: don't tell people they should sumbit a PR each time they see an outdated port | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Documentation | Reporter: | Ion-Mihai " IOnut " Tetcu <itetcu> | ||||
| Component: | Books & Articles | Assignee: | jcamou | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Ion-Mihai " IOnut " Tetcu
2005-05-06 01:00:19 UTC
On Fri, 6 May 2005, Ion-Mihai IOnut Tetcu wrote: > --- problem-reports_article.sgml.diff begins here --- > --- doc/en_US.ISO8859-1/articles/problem-reports/article.sgml.orig Fri May 6 02:41:02 2005 > +++ doc/en_US.ISO8859-1/articles/problem-reports/article.sgml Fri May 6 02:48:55 2005 > @@ -106,7 +106,15 @@ > <para>Notification of updates to externally maintained > software (mainly ports, but also externally maintained base > system components such as BIND or various GNU > - utilities).</para> > + utilities). In ports case there are 2 possibilities: the port > + has no maitainer (MAINTAINER=ports@freebsd.org) in which case > + if your PR doesn't contain a patch there are not many chances > + somebody will stand up and do it) or the port is maintained, > + in which case either the maintainer already knows about the > + update and for various reasons (no time, there's a problem in > + the new version, etc.) he hasn't submitted an update yet or if > + he doesn't know you should always try first to contact him > + directly and fill a PR only if you get no timle respose</para> This sentence could, well, use some work. Why not just "If you are reporting a new version of a port, try to contact the port's maintainer first."? Cheers, David Adam zanchey@ucc.gu.uwa.edu.au On Fri, 6 May 2005 08:55:52 +0800 (WST) David Adam <zanchey@ucc.gu.uwa.edu.au> wrote: > On Fri, 6 May 2005, Ion-Mihai IOnut Tetcu wrote: > > --- problem-reports_article.sgml.diff begins here --- > > --- doc/en_US.ISO8859-1/articles/problem-reports/article.sgml.orig Fri May 6 02:41:02 2005 > > +++ doc/en_US.ISO8859-1/articles/problem-reports/article.sgml Fri May 6 02:48:55 2005 > > @@ -106,7 +106,15 @@ > > <para>Notification of updates to externally maintained > > software (mainly ports, but also externally maintained base > > system components such as BIND or various GNU > > - utilities).</para> > > + utilities). In ports case there are 2 possibilities: the port > > + has no maitainer (MAINTAINER=ports@freebsd.org) in which case > > + if your PR doesn't contain a patch there are not many chances > > + somebody will stand up and do it) or the port is maintained, > > + in which case either the maintainer already knows about the > > + update and for various reasons (no time, there's a problem in > > + the new version, etc.) he hasn't submitted an update yet or if > > + he doesn't know you should always try first to contact him > > + directly and fill a PR only if you get no timle respose</para> > > This sentence could, well, use some work. yeh :) > Why not just "If you are reporting a new version of a port, try to contact > the port's maintainer first."? So that I don't see PR but post on ports@ ? Well, it will be an improvement, at least no one will have to close them. -- IOnut Unregistered ;) FreeBSD "user" > > Why not just "If you are reporting a new version of a port, try to contact > > the port's maintainer first."? > > So that I don't see PR but post on ports@ ? Well, it will be an > improvement, at least no one will have to close them. I have two primary problems with the proposed patch - It's poorly written. This can be fixed. - The general message that it gives is not one I think is beneficial. We should be trying to remove barriers for people to report problems, not institute them. I can understand that you want to reduce the amount of waffle in the PR database, but I think your proposed change is too complicated and too negative. Now, I am not a committer nor subscribed to ports@, but surely hitting the Delete key once or twice a week more often is not that huge a price to pay? I propose that this patch be shortened to: --- article.sgml.orig 2005-01-15 10:16:42.000000000 +0800 +++ article.sgml 2005-05-07 15:07:06.622424000 +0800 @@ -106,7 +106,8 @@ <para>Notification of updates to externally maintained software (mainly ports, but also externally maintained base system components such as BIND or various GNU - utilities).</para> + utilities). If you are reporting a new version of a + port, try contacting the port's maintainer first.</para> </listitem> </itemizedlist> David Adam zanchey@ucc.gu.uwa.edu.au On Sat, 7 May 2005 15:10:12 +0800 (WST) David Adam <zanchey@ucc.gu.uwa.edu.au> wrote: > > > Why not just "If you are reporting a new version of a port, try to contact > > > the port's maintainer first."? > > > > So that I don't see PR but post on ports@ ? Well, it will be an > > improvement, at least no one will have to close them. > > I have two primary problems with the proposed patch > - It's poorly written. This can be fixed. I hereby promise not to write any PR after 12p.m. localtime :) > - The general message that it gives is not one I think is beneficial. We > should be trying to remove barriers for people to report problems, not > institute them. You're somehow right here. > I can understand that you want to reduce the amount of waffle in the PR > database, but I think your proposed change is too complicated and too > negative. > > Now, I am not a committer nor subscribed to ports@, but surely hitting the > Delete key once or twice a week more often is not that huge a price to > pay? I remember having a discussion about this subject some time ago with pav@ (cc'ed). The only reason for "outdated announce" PR is that maybe someday someone other that a commiter (as a commiter is busy enough) will start looking in the PR database for something to do; now we all know how interested is the mythical Someone to do just that. IMO the practical value of this PR equals zero (even less since they generate supplementary work for the commiters - and the typical wait time for a non-commiter maintainer update is about a week this days). Now if the port is maintained, to have a PR announcing you there's a new version is usually frustrating: you know there's a new version, you probably have worked with the developer on it, you're probably testing to see there's no regression, etc. So this kind of PRs do the same good as a simple email (which can be useful if you maintain a large number of ports or for the ports that are updated rarely - I use a monthly cron job to remind me of them). > I propose that this patch be shortened to: > > --- article.sgml.orig 2005-01-15 10:16:42.000000000 +0800 > +++ article.sgml 2005-05-07 15:07:06.622424000 +0800 > @@ -106,7 +106,8 @@ > <para>Notification of updates to externally maintained > software (mainly ports, but also externally maintained base > system components such as BIND or various GNU > - utilities).</para> > + utilities). If you are reporting a new version of a > + port, try contacting the port's maintainer first.</para> > </listitem> > </itemizedlist> At least this could be committed. -- IOnut Unregistered ;) FreeBSD "user" Ion-Mihai Tetcu p=ED=B9e v so 07. 05. 2005 v 12:22 +0300: > > I propose that this patch be shortened to: > >=20 > > --- article.sgml.orig 2005-01-15 10:16:42.000000000 +0800 > > +++ article.sgml 2005-05-07 15:07:06.622424000 +0800 > > @@ -106,7 +106,8 @@ > > <para>Notification of updates to externally maintained > > software (mainly ports, but also externally maintained base > > system components such as BIND or various GNU > > - utilities).</para> > > + utilities). If you are reporting a new version of a > > + port, try contacting the port's maintainer first.</para> > > </listitem> > > </itemizedlist> >=20 > At least this could be committed. That, or just kill the whole paragraph. Or tell people to submit patch for updating the port with their PR. (Obviously this don't apply to base.) You could also tell people to search GNATS for PRs containing the update before sending any mail. --=20 Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> Linux is a happy free-for-all chaos. On 2005-05-07 11:41, Pav Lucistnik <pav@freebsd.org> wrote: >Ion-Mihai Tetcu p??e v so 07. 05. 2005 v 12:22 +0300: >>> I propose that this patch be shortened to: >>> >>> --- article.sgml.orig 2005-01-15 10:16:42.000000000 +0800 >>> +++ article.sgml 2005-05-07 15:07:06.622424000 +0800 >>> @@ -106,7 +106,8 @@ >>> <para>Notification of updates to externally maintained >>> software (mainly ports, but also externally maintained base >>> system components such as BIND or various GNU >>> - utilities).</para> >>> + utilities). If you are reporting a new version of a >>> + port, try contacting the port's maintainer first.</para> >>> </listitem> >>> </itemizedlist> >> >> At least this could be committed. > > That, or just kill the whole paragraph. > > Or tell people to submit patch for updating the port with their PR. > (Obviously this don't apply to base.) > > You could also tell people to search GNATS for PRs containing the update > before sending any mail. IMHO, this should apply to *ALL* submissions through Gnats. I don't see why we have to mention it especially for ports/ stuff. # itetcu@people.tecnik93.com / 2005-05-07 12:22:26 +0300: > The only reason for "outdated announce" PR is that maybe someday someone > other that a commiter (as a commiter is busy enough) will start looking > in the PR database for something to do; now we all know how interested > is the mythical Someone to do just that. IMO the practical value of this > PR equals zero (even less since they generate supplementary work for the > commiters - and the typical wait time for a non-commiter maintainer > update is about a week this days). > > Now if the port is maintained, to have a PR announcing you there's a new > version is usually frustrating: you know there's a new version, you > probably have worked with the developer on it, you're probably testing > to see there's no regression, etc. So this kind of PRs do the same good > as a simple email (which can be useful if you maintain a large number of > ports or for the ports that are updated rarely - I use a monthly cron > job to remind me of them). I used the above text as a base for this patch; I haven't tested it compiles. Index: en_US.ISO8859-1/articles/problem-reports/article.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/articles/problem-reports/article.sgml,v retrieving revision 1.36 diff -u -u -r1.36 article.sgml --- en_US.ISO8859-1/articles/problem-reports/article.sgml 15 Jan 2005 02:16:42 -0000 1.36 +++ en_US.ISO8859-1/articles/problem-reports/article.sgml 8 May 2005 10:11:30 -0000 @@ -107,6 +107,20 @@ software (mainly ports, but also externally maintained base system components such as BIND or various GNU utilities).</para> + <para>For unmaintained ports (<makevar>MAINTAINER</makevar> contains + <literal>ports@FreeBSD.org</literal>), such update notifications + might get picked up by an interested + committer, or you might be asked to provide a patch to update + the port; providing it upfront will greatly improve your chances + that the port will get updated in a timely manner.</para> + <para>If the port is maintained, PRs announcing new upstream releases + are usually not very useful since they generate supplementary work + for the commiters, and the maintainer likely knows already there's + a new version, they have probably worked with the developers on it, + they're probably testing to see there's no regression, etc.</para> + <para>In either case, following the process described in <ulink + url="&url.books.porters-handbook;/port-upgrading.html">Porter's + Handbook</ulink> will yield the best results.</para> </listitem> </itemizedlist> -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 On Sun, 8 May 2005 12:17:08 +0200 Roman Neuhauser <neuhauser@sigpipe.cz> wrote: > # itetcu@people.tecnik93.com / 2005-05-07 12:22:26 +0300: > > The only reason for "outdated announce" PR is that maybe someday someone > > other that a commiter (as a commiter is busy enough) will start looking > > in the PR database for something to do; now we all know how interested > > is the mythical Someone to do just that. IMO the practical value of this > > PR equals zero (even less since they generate supplementary work for the > > commiters - and the typical wait time for a non-commiter maintainer > > update is about a week this days). > > > > Now if the port is maintained, to have a PR announcing you there's a new > > version is usually frustrating: you know there's a new version, you > > probably have worked with the developer on it, you're probably testing > > to see there's no regression, etc. So this kind of PRs do the same good > > as a simple email (which can be useful if you maintain a large number of > > ports or for the ports that are updated rarely - I use a monthly cron > > job to remind me of them). > > I used the above text as a base for this patch; I haven't tested > it compiles. > > Index: en_US.ISO8859-1/articles/problem-reports/article.sgml > =================================================================== > RCS file: /home/ncvs/doc/en_US.ISO8859-1/articles/problem-reports/article.sgml,v > retrieving revision 1.36 > diff -u -u -r1.36 article.sgml > --- en_US.ISO8859-1/articles/problem-reports/article.sgml 15 Jan 2005 02:16:42 -0000 1.36 > +++ en_US.ISO8859-1/articles/problem-reports/article.sgml 8 May 2005 10:11:30 -0000 > @@ -107,6 +107,20 @@ > software (mainly ports, but also externally maintained base > system components such as BIND or various GNU > utilities).</para> > + <para>For unmaintained ports (<makevar>MAINTAINER</makevar> contains > + <literal>ports@FreeBSD.org</literal>), such update notifications > + might get picked up by an interested > + committer, or you might be asked to provide a patch to update > + the port; providing it upfront will greatly improve your chances > + that the port will get updated in a timely manner.</para> > + <para>If the port is maintained, PRs announcing new upstream releases > + are usually not very useful since they generate supplementary work > + for the commiters, and the maintainer likely knows already there's > + a new version, they have probably worked with the developers on it, > + they're probably testing to see there's no regression, etc.</para> > + <para>In either case, following the process described in <ulink > + url="&url.books.porters-handbook;/port-upgrading.html">Porter's > + Handbook</ulink> will yield the best results.</para> > </listitem> > </itemizedlist> I'd say it better that my original and should be committed. -- IOnut Unregistered ;) FreeBSD "user" Responsible Changed From-To: freebsd-doc->jcamou Take it. State Changed From-To: open->closed Patch committed with some changes, thanks for the submission. |
