Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Jason Zaman <jason@perfinion.com>]

On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote:
> On Mon, 15 Aug 2016 11:45:22 +0800
> Jason Zaman <perfinion@gentoo.org> wrote:
> 
> > IN_PROGRESS == we've put the fix in the git repo
> > RESO/TESTREQ == new release and in ~arch
> 
> TESTREQ was incidentally my first thought. Only needs me to study how much that's already used
> and whether or not existing bugs with that flag meet that description or not.
> 
> 
> However, a distinction between IN_PROGRESS and RESO/TESTREQ is not possible here,
> because "in git" means "You'll get it if you sync >1h from now"

Oh, I meant this is for our policy stuff. which is in
hardened-refpolicy.git and then every few weeks we make a release and
bump all the packages in sec-policy/selinux-*. For things that do not
need an actual release we just skip INPROG and go straight to TESTREQ
when we fix the ebuild in the tree.

The important part to me is that RESO/FIXED should only mean fixed when
the problem is fixed in the stable tree too. There has to be another
state before FIXED that is for ~arch. If the package is not stable on
any arch then of course it is FIXED as soon as ~arch is fixed.

> IN_PROGRESS can thus only mean something about it being worked on but not yet pushed
> to the main git repo. (ie: overlays, private repos)
> 
> But I would rather it part of the primary resolution path, not a mere property of the resolution type.
> 
> Because its easier to say:
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE
> 
> Than
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) -> (RESOLVED/FIXED)

They are roughly equivalent, yeah. But I prefer TESTREQ because its
easier to see in the bug list page. You can of course choose which items
are shown in the list in bugzilla but resolution is already there so no
need to add an extra column.

-- Jason