| 1 |
On Fri, 17 Jun 2016 18:46:16 +0200 |
| 2 |
Kristian Fiskerstrand <k_f@g.o> wrote: |
| 3 |
|
| 4 |
> On 06/17/2016 06:41 PM, Rich Freeman wrote: |
| 5 |
> > On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand |
| 6 |
> > <k_f@g.o> wrote: |
| 7 |
> >> On 06/17/2016 03:58 PM, Rich Freeman wrote: |
| 8 |
> >>> |
| 9 |
> >>> That could actually be generalized. I could see many types of |
| 10 |
> >>> bugs where the issue is with upstream, and we might want to track |
| 11 |
> >>> the progress as upstream implements a fix, releases it, and then |
| 12 |
> >>> it is stabilized on Gentoo. So, maybe we need another state to |
| 13 |
> >>> track in upstream's VCS vs the Gentoo repo. |
| 14 |
> >> |
| 15 |
> >> For a great deal of this we have UPSTREAM keyword, and also |
| 16 |
> >> combination with PATCH keyword if we've submitted an own patch. |
| 17 |
> > |
| 18 |
> > Usually we mean UPSTEAM to mean that the issue is an upstream issue, |
| 19 |
> > and should be pursued there. Usually we don't use it to mean that |
| 20 |
> > the issue IS resolved upstream but we're waiting for a |
| 21 |
> > release/etc. I'm |
| 22 |
> |
| 23 |
> Well, the issue is still upstream in that case, so I don't see that |
| 24 |
> necessarily being different, we're still waiting for a release |
| 25 |
> upstream to make a new downstream ebuild and stabilize it, so it fits |
| 26 |
> with UPSTREAM |
| 27 |
> |
| 28 |
> > not sure how important the distinction is in practice. The portage |
| 29 |
> > team could of course use it differently. |
| 30 |
> |
| 31 |
> Yeah, I'm talking ebuilds here, not portage and similar bugs, I think |
| 32 |
> your point of having own keyword for portage and the likes makes sense |
| 33 |
> to distinguish it. |
| 34 |
> |
| 35 |
> |
| 36 |
|
| 37 |
Then everyone PLEASE stop referring to the Gentoo ebuild tree as |
| 38 |
portage. Reserve portage for the upstream PACKAGE MANAGER. |
| 39 |
|
| 40 |
|
| 41 |
Further, I have always treated bugs about portage code like any |
| 42 |
other upstream. Only difference being that the portage upstream bug |
| 43 |
system is the same bugzilla used for the Gentoo ebuild tree. |
| 44 |
So, there will be some differences in how bugs are treated. |
| 45 |
When we as upstream commit patches for bugs we tag them as InVCS and |
| 46 |
close them when they are in a release. We have not kept them open |
| 47 |
until that release has been stabilized unless we've missed closing it |
| 48 |
or been distracted and forgotten to clean them up. |
| 49 |
|
| 50 |
If you want to track that at the ebuild level, you could do that, but |
| 51 |
would need to identify it's tracker in a clear way to distinguish it |
| 52 |
from code bugs. |
| 53 |
-- |
| 54 |
Brian Dolbec <dolsen> |
Archives