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

[Brian Dolbec]

On Mon, 15 Aug 2016 09:40:39 -0400
Rich Freeman <rich0@g.o> wrote:

> On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec <dolsen@g.o>
> wrote:
> >
> > 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.
>
> I'd suggest that we agree early-on that the scope of this is around
> ebuild work.  Not "upstream" work where the upstream is Gentoo.
>
> Of course, there could be overlap.  portage-1.23.ebuild might have a
> bug, and that gets fixed in the portage dev git, and later gets
> released to portage-1.24, and then ends up in stable sometime later.
> Those could be two separate bugs (the gentoo repo ebuild bug vs the
> portage "upstream" bug), but I'm not sure that makes life easier.  If
> they were two separate bugs (as they would be if Gentoo weren't the
> upstream) then the scope of this effort is focused on the Gentoo
> ebuild repo bug.
>

I suppose we could use the tracker bug a little differently than we
have to handle the release/ebuild stabilization process. We have often
recycled a tracker to the next version, but instead we can generate a
new one each time and allow it to be used this way.  If a release is
being skipped for stabilization, then it could be added to the next
tracker's depend.

The only thing is that we will still end up with duplicate bugs being
filed since the trackers do not have any search data of the original
bugs which have been fixed and released in an unstable version.  Of
which the original bug had been marked resolved.  In this case, could
the search system be modified to keep that search data until all
references to that bug (ie: blocks the tracker bug) have been
stabilized/closed.


hmm, looking a bugzilla...

Gentoo Linux: 	The Gentoo Linux Distribution – Ebuilds and
System related issues Always attach the output of emerge --info to your
bug report! 

Before reporting a bug, please make sure the issue you are about to
file is not the result of a misconfiguration on your part. Our other
support venues (for instance the Forums or IRC channels) can help you
find out whether the issue warrants a bug report. 

Examples for bugs in this product:
    New package and version bump requests
    Compile errors (please follow the instructions contained in the
    error message!) Application crashes (be sure to have a backtrace
    available) General issues regarding your Gentoo system

Examples for bugs that should NOT be filed here:
    Security updates (use Gentoo Security below)
    Documentation updates (use Documentation below)
    Issues regarding our website and infrastructure (use Gentoo
    Infrastructure or Website www.gentoo.org below) Issues about OpenRC,
    genkernel, or catalyst (use Hosted projects below)


------

This is still a very broad range...  This can still cover bugs for many
small projects that are not in the hosted projects category. It also
can contain bugs that will never involve stabilization of an ebuild. 

Perhaps we need to add a new category SPECIFICALLY for dealing with the
stabilization process and/or Gentoo tree state.  The current "Gentoo
Linux" would continue to act as the catch-all, but as a bug is fixed and
involves a release/in tree new version,..., it get's re-categorized to a
"Gentoo Stabilization" (or some other aptly named) category.  In that
way, once a fix has been made the re-categorization could reduce the
search results for projects working on bugs that need fixing.  While at
the same time, not completely close a bug.  For tracker bugs, it would
be the tracker that gets re-categorized to the specific "Gentoo
Stabilization" category where it too could get better search
results and/or some semi-automated tools could send reminders for
ebuilds not stabilized after the 30 day time when that version has no
bugs in the catch-all category.  Also if bugs are filed against it, a
tool could auto-tag it's DEPEND with the "Gentoo Linux" bug number.

I think something like this could help improve the process.
-- 
Brian Dolbec <dolsen>