On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote: > On Mon, 15 Aug 2016 11:45:22 +0800 > Jason Zaman <perfin...@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
