Gentoo Archives: gentoo-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree
Date: Mon, 15 Aug 2016 15:49:07
In Reply to: Re: [gentoo-dev] New Working Group established to evaluate the stable tree by Rich Freeman
1 On Mon, 15 Aug 2016 09:40:39 -0400
2 Rich Freeman <rich0@g.o> wrote:
4 > On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec <dolsen@g.o>
5 > wrote:
6 > >
7 > > I have some trouble with not being able to close bugs as resolved
8 > > when the fixes have been released. But I do see that the majority
9 > > of what is being discussed relates to pkg ebuilds more than it does
10 > > to coding projects. In that sense it sounds reasonable. But for
11 > > me, most of my work is project coding, so it overlaps with making
12 > > releases which involves the ebuild. As a project coder, I want to
13 > > be able to close a bug when a release has been made that contains
14 > > the fix. In some cases that release might not get stabilized, but
15 > > another one later does.
16 >
17 > I'd suggest that we agree early-on that the scope of this is around
18 > ebuild work. Not "upstream" work where the upstream is Gentoo.
19 >
20 > Of course, there could be overlap. portage-1.23.ebuild might have a
21 > bug, and that gets fixed in the portage dev git, and later gets
22 > released to portage-1.24, and then ends up in stable sometime later.
23 > Those could be two separate bugs (the gentoo repo ebuild bug vs the
24 > portage "upstream" bug), but I'm not sure that makes life easier. If
25 > they were two separate bugs (as they would be if Gentoo weren't the
26 > upstream) then the scope of this effort is focused on the Gentoo
27 > ebuild repo bug.
28 >
30 I suppose we could use the tracker bug a little differently than we
31 have to handle the release/ebuild stabilization process. We have often
32 recycled a tracker to the next version, but instead we can generate a
33 new one each time and allow it to be used this way. If a release is
34 being skipped for stabilization, then it could be added to the next
35 tracker's depend.
37 The only thing is that we will still end up with duplicate bugs being
38 filed since the trackers do not have any search data of the original
39 bugs which have been fixed and released in an unstable version. Of
40 which the original bug had been marked resolved. In this case, could
41 the search system be modified to keep that search data until all
42 references to that bug (ie: blocks the tracker bug) have been
43 stabilized/closed.
46 hmm, looking a bugzilla...
48 Gentoo Linux: The Gentoo Linux Distribution – Ebuilds and
49 System related issues Always attach the output of emerge --info to your
50 bug report!
52 Before reporting a bug, please make sure the issue you are about to
53 file is not the result of a misconfiguration on your part. Our other
54 support venues (for instance the Forums or IRC channels) can help you
55 find out whether the issue warrants a bug report.
57 Examples for bugs in this product:
58 New package and version bump requests
59 Compile errors (please follow the instructions contained in the
60 error message!) Application crashes (be sure to have a backtrace
61 available) General issues regarding your Gentoo system
63 Examples for bugs that should NOT be filed here:
64 Security updates (use Gentoo Security below)
65 Documentation updates (use Documentation below)
66 Issues regarding our website and infrastructure (use Gentoo
67 Infrastructure or Website below) Issues about OpenRC,
68 genkernel, or catalyst (use Hosted projects below)
71 ------
73 This is still a very broad range... This can still cover bugs for many
74 small projects that are not in the hosted projects category. It also
75 can contain bugs that will never involve stabilization of an ebuild.
77 Perhaps we need to add a new category SPECIFICALLY for dealing with the
78 stabilization process and/or Gentoo tree state. The current "Gentoo
79 Linux" would continue to act as the catch-all, but as a bug is fixed and
80 involves a release/in tree new version,..., it get's re-categorized to a
81 "Gentoo Stabilization" (or some other aptly named) category. In that
82 way, once a fix has been made the re-categorization could reduce the
83 search results for projects working on bugs that need fixing. While at
84 the same time, not completely close a bug. For tracker bugs, it would
85 be the tracker that gets re-categorized to the specific "Gentoo
86 Stabilization" category where it too could get better search
87 results and/or some semi-automated tools could send reminders for
88 ebuilds not stabilized after the 30 day time when that version has no
89 bugs in the catch-all category. Also if bugs are filed against it, a
90 tool could auto-tag it's DEPEND with the "Gentoo Linux" bug number.
92 I think something like this could help improve the process.
93 --
94 Brian Dolbec <dolsen>