nightmorph 07/02/14 21:30:16 Modified: bugzilla-howto.xml Log: added a section on zero-day bump requests to the bugzilla guide for bug 166809
Revision Changes Path 1.9 xml/htdocs/doc/en/bugzilla-howto.xml file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml?rev=1.9&view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml?rev=1.9&content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml?r1=1.8&r2=1.9 Index: bugzilla-howto.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- bugzilla-howto.xml 10 Nov 2006 22:19:40 -0000 1.8 +++ bugzilla-howto.xml 14 Feb 2007 21:30:15 -0000 1.9 @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v 1.8 2006/11/10 22:19:40 nightmorph Exp $ --> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v 1.9 2007/02/14 21:30:15 nightmorph Exp $ --> <guide link="/doc/en/bugzilla-howto.xml"> <title>Gentoo Bug Reporting Guide</title> @@ -20,8 +20,8 @@ <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> <license/> -<version>1.7</version> -<date>2006-11-10</date> +<version>1.8</version> +<date>2007-02-14</date> <chapter> <title>Introduction</title> @@ -958,6 +958,61 @@ </body> </section> +<section> +<title>Zero-day bump requests</title> +<body> + +<p> +So far, we've shown what to do when filing a bug. Now let's take a look at what +<e>not</e> to do. +</p> + +<p> +Suppose that you've eagerly been following an upstream project's schedule, and +when you check their homepage, guess what? They just released a new version a +few minutes ago! Most users would immediately rush over to Gentoo's bugzilla to +report the new version is available; please bump the existing version and add +it to Portage, etc. However, this is exactly what you should <b>not</b> do. +These kinds of requests are called zero-day (or 0-day) bump requests, as they're +made the same day that a new version is released. +</p> + +<impo> +<b>Please wait <e>at least</e> 48 hours before reporting a new release on our +bugzilla.</b> Also, you <e>must</e> check bugzilla before posting your request +to make sure that someone else hasn't already reported it, or that the Gentoo +maintainers haven't already dealt with the new version. +</impo> + +<p> +Why should you wait? First, it's quite rude to demand that Gentoo developers +drop everything they're doing just to add a new release that came out 15 minutes +ago. Your zero-day bump request could be marked as INVALID or LATER, as +developers have plenty of pressing issues to keep them busy. Second, developers +are usually aware of pending new releases well in advance of users, as they must +follow upstream quite closely. They already know a new version is on its way. +In many cases, they will have already opened a bug, or might even already added +it in Portage as a masked package. +</p> + +<p> +Be smart when testing and requesting new versions of packages. Search bugzilla +before posting your bump request -- is there already a bug open? Have you synced +lately; is it already in Portage? Has it actually been released by upstream? +Basic common sense will go a long way, and will endear you to developers that +already have a lot to do. If it's been several days since release and you're +sure that there are no open requests for it (and that it's not in Portage), then +you can open up a new bug. Be sure to mention that it compiles and runs well on +your arch. Any other helpful information you provide is most welcome. +</p> + +<p> +Want to see the newest version of your favorite package in Portage? File smart +bugs. +</p> + +</body> +</section> </chapter> <chapter> -- [email protected] mailing list
