On Fri, 17 Jun 2016 18:46:16 +0200 Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 06/17/2016 06:41 PM, Rich Freeman wrote: > > On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand > > <k...@gentoo.org> wrote: > >> On 06/17/2016 03:58 PM, Rich Freeman wrote: > >>> > >>> That could actually be generalized. I could see many types of > >>> bugs where the issue is with upstream, and we might want to track > >>> the progress as upstream implements a fix, releases it, and then > >>> it is stabilized on Gentoo. So, maybe we need another state to > >>> track in upstream's VCS vs the Gentoo repo. > >> > >> For a great deal of this we have UPSTREAM keyword, and also > >> combination with PATCH keyword if we've submitted an own patch. > > > > Usually we mean UPSTEAM to mean that the issue is an upstream issue, > > and should be pursued there. Usually we don't use it to mean that > > the issue IS resolved upstream but we're waiting for a > > release/etc. I'm > > Well, the issue is still upstream in that case, so I don't see that > necessarily being different, we're still waiting for a release > upstream to make a new downstream ebuild and stabilize it, so it fits > with UPSTREAM > > > not sure how important the distinction is in practice. The portage > > team could of course use it differently. > > Yeah, I'm talking ebuilds here, not portage and similar bugs, I think > your point of having own keyword for portage and the likes makes sense > to distinguish it. > > Then everyone PLEASE stop referring to the Gentoo ebuild tree as portage. Reserve portage for the upstream PACKAGE MANAGER. Further, I have always treated bugs about portage code like any other upstream. Only difference being that the portage upstream bug system is the same bugzilla used for the Gentoo ebuild tree. So, there will be some differences in how bugs are treated. When we as upstream commit patches for bugs we tag them as InVCS and close them when they are in a release. We have not kept them open until that release has been stabilized unless we've missed closing it or been distracted and forgotten to clean them up. If you want to track that at the ebuild level, you could do that, but would need to identify it's tracker in a clear way to distinguish it from code bugs. -- Brian Dolbec <dolsen>
pgp69AoKFcWN9.pgp
Description: OpenPGP digital signature
