From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OtCTZ-0000pv-2y for garchives@archives.gentoo.org; Wed, 08 Sep 2010 04:41:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E6EC7E0978; Wed, 8 Sep 2010 04:41:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E6454E04C1 for ; Wed, 8 Sep 2010 04:40:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 592B81B40DB for ; Wed, 8 Sep 2010 04:40:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 required=5.5 tests=[AWL=0.514, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS7yeZRBJ9nB for ; Wed, 8 Sep 2010 04:40:51 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id 491D51B40A3 for ; Wed, 8 Sep 2010 04:40:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OtCSi-0007Eq-1R for gentoo-dev@gentoo.org; Wed, 08 Sep 2010 06:40:44 +0200 Received: from static24-72-114-21.yk.rev.accesscomm.ca ([24.72.114.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 06:40:44 +0200 Received: from dirtyepic by static24-72-114-21.yk.rev.accesscomm.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 06:40:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Ryan Hill Subject: [gentoo-dev] Re: RFC Bugzilla interaction guide for devs & editbugs users Date: Tue, 7 Sep 2010 22:44:48 -0600 Message-ID: <20100907224448.15e93f74@gentoo.org> References: <20100907224727.5d6ccfae@amit.kihnet.sk> <20100907214459.GA11425@laptop> <1283897135.4629.3.camel@localhost.localdomain> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/DiIMX0qVHe/T/3eRjJ.bwcf"; protocol="application/pgp-signature" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: static24-72-114-21.yk.rev.accesscomm.ca X-Newsreader: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-unknown-linux-gnu) X-Archives-Salt: d26a21df-1592-4fa2-aa36-5bf376f1abc5 X-Archives-Hash: 04d29af0840684fbb6691add97481962 --Sig_/DiIMX0qVHe/T/3eRjJ.bwcf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 7 Sep 2010 22:53:22 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> wrote: > Pacho Ramos posted on Wed, 08 Sep 2010 00:05:34 +0200 as excerpted: >=20 > > El mi=E9, 08-09-2010 a las 01:44 +0400, dev-random@mail.ru escribi=F3: > >> On Tue, Sep 07, 2010 at 09:30:34PM +0000, Robin H. Johnson wrote: > >> > This implies that the upstream is alive enough to fix it. > >> >=20 > >> > I feel it should mean that the bug has been reported to upstream, and > >> > that state is documented in the bug. > >> >=20 > >> > If we keep every upstream bug open instead of closed, we'd have > >> > probably another 2500 open bugs (5312 RESO/UPSTREAM in the history of > >> > Gentoo, and I'm ballparking that 50% aren't actually fixed yet > >> > upstream). > >>=20 > >> Bug may be a blocker. And marking it as RESOLVED/UPSTREAM you may > >> unblock another bug (e.g. stabilization request) which should be still > >> blocked because there is no fixed package in tree. > >>=20 > >>=20 > > In most cases when it's really a blocker, bug will remain opened anyway > > until solved or, if not possible, stabilization will be postponed. >=20 > Additionally, RESOLVED/UPSTREAM indicates that the Gentoo package=20 > maintainer (or other dev who marked it such) believes Gentoo is not the=20 > appropriate place for a patch fixing the problem. >=20 > As such, the bug will never be fixed at the Gentoo level, only upstream,= =20 > and if there's a blocker on it, the blocker would never get resolved=20 > either, until upstream fixes it. Where upstream isn't active or doesn't= =20 > believe the fix appropriate either, that'd lead to stalemate and forever= =20 > blocking the dependent Gentoo bug. That's not appropriate either. Sure it is. That's what a blocker is. The bug isn't fixed. How can the action requiring that the bug be fixed to happen take place? What isn't appropriate is resolving bugs blocking other bugs as RESO/UPSTRE= AM in the first place. It basically takes us out of the loop. Even if the bug might be fixed better upstream, the bug report in which this is determined should not be closed until the bug is fixed in Gentoo. It becomes the tracker of the upstream progress of the bug, and the later reintegration of the solution back into Gentoo. That is, after all, what the dependency bug is concerned with. =20 > So RESOLVED/UPSTREAM *should* unblock blockers, even where upstream=20 > doesn't resolve, or we've simply created a deadlock that's not going to b= e=20 > resolved. If it's truly a blocker, the problem will need worked around=20 > some other way. But often, "blockers" really aren't blockers, when=20 > upstream chooses not to take the package in that direction after all. It= =20 > simply means some other alternative, perhaps an alternative package, must= =20 > be developed instead, and the package as it is can continue to evolve in= =20 > the normal way. No. Here's my scenario. gcc-porting creates a tracker bug everytime GCC trunk hits stage 3 for the upcoming version where all packages with build errors get added as blockers. In the early throes of this process, where many packagers (understandably) couldn't give two shits about a GCC version that they've never heard of I get many bugs closed as RESO/INVALID or RESO/UPSTREAM. Th= is encompasses the "not my problem, take it upstream" definition of RESO/UPSTREAM, and I respect this. Meanwhile the package is still broken a= nd while the patches I have do go upstream, I have no way of tracking when the= se fixes get into Gentoo without personally and obsessively tracking their individual progress, which, sadly, I do (see the gcc-porting overlay). Later as release approaches and people are more amenable, I sometimes get t= he "I sent this upstream, they've applied it" RESO/UPSTREAM. Again, this doesn= 't help us. The Gentoo package is still broken. These I just reopen with a n= ote saying close it when the fix reaches portage, generally because at this poi= nt I'm too burnt out by stage 1 above. At release time we always get a few high profile projects shun the new release for breaking their favorite feature and decree on high they will not support it. RESO/UPSTREAM seems designed for these types of bugs, surely we can use it here! Nope. It's still broken. We judge how ready we are to unmask new major compiler releases by looking at how many _open_ bugs there are on the tracker. If these types of high-profile bugs are RESO/UPSTREAM, they will probably get overlooked, like I almost missed emacs (twice!) earlier in the 4.5 cycle. The point is, no matter how you interpret it, RESO/UPSTREAM is never a good idea for bugs blocking others. I have no problem how you use it outside that context. --=20 fonts, gcc-porting, we hold our breath, we spin around the world toolchain, wxwidgets you and me cling to the outside of the earth @ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 06= 62 --Sig_/DiIMX0qVHe/T/3eRjJ.bwcf Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkyHFMQACgkQiqiDRvmkBmKlCwCeJw3pDySocC1uLJ7lZ950uRvl p1UAmgIjqdb86zcBvcRL52TZFrcuUlrd =etAk -----END PGP SIGNATURE----- --Sig_/DiIMX0qVHe/T/3eRjJ.bwcf--