1 |
On Mon, 15 Aug 2016 12:05:43 +0800 |
2 |
Jason Zaman <jason@×××××××××.com> wrote: |
3 |
|
4 |
> On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote: |
5 |
> > On Mon, 15 Aug 2016 11:45:22 +0800 |
6 |
> > Jason Zaman <perfinion@g.o> wrote: |
7 |
> > |
8 |
> > > IN_PROGRESS == we've put the fix in the git repo |
9 |
> > > RESO/TESTREQ == new release and in ~arch |
10 |
> > |
11 |
> > TESTREQ was incidentally my first thought. Only needs me to study |
12 |
> > how much that's already used and whether or not existing bugs with |
13 |
> > that flag meet that description or not. |
14 |
> > |
15 |
> > |
16 |
> > However, a distinction between IN_PROGRESS and RESO/TESTREQ is not |
17 |
> > possible here, because "in git" means "You'll get it if you sync |
18 |
> > >1h from now" |
19 |
> |
20 |
> Oh, I meant this is for our policy stuff. which is in |
21 |
> hardened-refpolicy.git and then every few weeks we make a release and |
22 |
> bump all the packages in sec-policy/selinux-*. For things that do not |
23 |
> need an actual release we just skip INPROG and go straight to TESTREQ |
24 |
> when we fix the ebuild in the tree. |
25 |
> |
26 |
> The important part to me is that RESO/FIXED should only mean fixed |
27 |
> when the problem is fixed in the stable tree too. There has to be |
28 |
> another state before FIXED that is for ~arch. If the package is not |
29 |
> stable on any arch then of course it is FIXED as soon as ~arch is |
30 |
> fixed. |
31 |
> |
32 |
> > IN_PROGRESS can thus only mean something about it being worked on |
33 |
> > but not yet pushed to the main git repo. (ie: overlays, private |
34 |
> > repos) |
35 |
> > |
36 |
> > But I would rather it part of the primary resolution path, not a |
37 |
> > mere property of the resolution type. |
38 |
> > |
39 |
> > Because its easier to say: |
40 |
> > |
41 |
> > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE |
42 |
> > |
43 |
> > Than |
44 |
> > |
45 |
> > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) -> |
46 |
> > (RESOLVED/FIXED) |
47 |
> |
48 |
> They are roughly equivalent, yeah. But I prefer TESTREQ because its |
49 |
> easier to see in the bug list page. You can of course choose which |
50 |
> items are shown in the list in bugzilla but resolution is already |
51 |
> there so no need to add an extra column. |
52 |
> |
53 |
> -- Jason |
54 |
> |
55 |
> |
56 |
|
57 |
I have some trouble with not being able to close bugs as resolved when |
58 |
the fixes have been released. But I do see that the majority of what is |
59 |
being discussed relates to pkg ebuilds more than it does to coding |
60 |
projects. In that sense it sounds reasonable. But for me, most of my |
61 |
work is project coding, so it overlaps with making releases which |
62 |
involves the ebuild. As a project coder, I want to be able to close a |
63 |
bug when a release has been made that contains the fix. In some cases |
64 |
that release might not get stabilized, but another one later does. |
65 |
|
66 |
For me IN_PROGRESS means the problem is being worked on, not that a fix |
67 |
has been posted/committed anywhere. INVCS is once the fix has been |
68 |
committed to the source repo and not anything to do with an ebuild from |
69 |
the coders perspective. The problem is the overlap of bugzilla for |
70 |
both ebuild repositories and source repositories. So if there is any |
71 |
changes to be made to the different states possible... Just remember |
72 |
the the different perspectives and try to make it clear what they are |
73 |
for. Also, if a pkg is never stabilized... does that mean it's bugs |
74 |
can never be closed? So far in the discussion, that point has not been |
75 |
brought up, but is very relevant to the discussion. |
76 |
|
77 |
/me mumbles about the extra bookeeping that work-flow will |
78 |
make...and subsequently put off and/or forget to do ;) |
79 |
|
80 |
-- |
81 |
Brian Dolbec <dolsen> |