On Tue, 7 Sep 2010 22:53:22 +0000 (UTC) Duncan <1i5t5.dun...@cox.net> wrote:
> Pacho Ramos posted on Wed, 08 Sep 2010 00:05:34 +0200 as excerpted: > > > El mié, 08-09-2010 a las 01:44 +0400, dev-ran...@mail.ru escribió: > >> 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. > >> > > >> > I feel it should mean that the bug has been reported to upstream, and > >> > that state is documented in the bug. > >> > > >> > 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). > >> > >> 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. > >> > >> > > In most cases when it's really a blocker, bug will remain opened anyway > > until solved or, if not possible, stabilization will be postponed. > > Additionally, RESOLVED/UPSTREAM indicates that the Gentoo package > maintainer (or other dev who marked it such) believes Gentoo is not the > appropriate place for a patch fixing the problem. > > As such, the bug will never be fixed at the Gentoo level, only upstream, > and if there's a blocker on it, the blocker would never get resolved > either, until upstream fixes it. Where upstream isn't active or doesn't > believe the fix appropriate either, that'd lead to stalemate and forever > 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/UPSTREAM 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. > So RESOLVED/UPSTREAM *should* unblock blockers, even where upstream > doesn't resolve, or we've simply created a deadlock that's not going to be > resolved. If it's truly a blocker, the problem will need worked around > some other way. But often, "blockers" really aren't blockers, when > upstream chooses not to take the package in that direction after all. It > simply means some other alternative, perhaps an alternative package, must > be developed instead, and the package as it is can continue to evolve in > 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. This encompasses the "not my problem, take it upstream" definition of RESO/UPSTREAM, and I respect this. Meanwhile the package is still broken and while the patches I have do go upstream, I have no way of tracking when these 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 the "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 note saying close it when the fix reaches portage, generally because at this point 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. -- 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 0662
signature.asc
Description: PGP signature
