On Mon, 15 Aug 2016 12:05:43 +0800 Jason Zaman <ja...@perfinion.com> wrote:
> 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 > > I have some trouble with not being able to close bugs as resolved when the fixes have been released. But I do see that the majority of what is being discussed relates to pkg ebuilds more than it does to coding projects. In that sense it sounds reasonable. But for me, most of my work is project coding, so it overlaps with making releases which involves the ebuild. As a project coder, I want to be able to close a bug when a release has been made that contains the fix. In some cases that release might not get stabilized, but another one later does. For me IN_PROGRESS means the problem is being worked on, not that a fix has been posted/committed anywhere. INVCS is once the fix has been committed to the source repo and not anything to do with an ebuild from the coders perspective. The problem is the overlap of bugzilla for both ebuild repositories and source repositories. So if there is any changes to be made to the different states possible... Just remember the the different perspectives and try to make it clear what they are for. Also, if a pkg is never stabilized... does that mean it's bugs can never be closed? So far in the discussion, that point has not been brought up, but is very relevant to the discussion. /me mumbles about the extra bookeeping that work-flow will make...and subsequently put off and/or forget to do ;) -- Brian Dolbec <dolsen>
