Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Kristian Fiskerstrand]

On 06/17/2016 07:05 PM, Brian Dolbec wrote:
> On Fri, 17 Jun 2016 18:46:16 +0200
> Kristian Fiskerstrand <k_f@g.o> wrote:
>
>> On 06/17/2016 06:41 PM, Rich Freeman wrote:
>>> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
>>> <k_f@g.o> 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.

indeed

>
>
> 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.
>

It might not be much of an issue as long as we use proper categories for
own hosted repos, then InVCS function is overloaded and means different
things for the ebuild bugs and the upstream package bugs without any
conflict. Would potentially result in some duplication of material bugs
though hence that might be easier by adding a new keyword with explicit
separate meaning for things.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3