Re: [gentoo-dev] rfc: stabilization policies

[Wyatt Epp]

On Wed, Aug 21, 2013 at 5:50 AM, Sergey Popov <pinkbyte@g.o> wrote:
>
> As i said earlier, we should recruit more people -> then problem will go
> away.

This is a point most of the people in this thread seem to be dancing
around that's sort of problematic.  You can talk about recruiting
until you're blue in the face, but the simple fact is Gentoo DOESN'T
have adequate manpower.  And has it ever, really?  Can you honestly
say we've ever had a solid surplus of devs with time [0]?  We've
gotten where we are, by and large, because Gentoo works smarter.

Fundamentally, I see this as a problem of tooling.

Let's turn the question around; try thinking about it like this: What
tools have historically allowed relatively few active developers
handle stablisation and integration of upstream patch flow IN SPITE of
not having a lot of recruits?  What tools could be added to assist
with, if not outright _remove_ steps of the process?

I'd like to point out something that jumped out to me as a red flag
earlier (not to pick on you specifically, Tom; this is just the
cleanest example I saw), and turn it into an example:

On Wed, Aug 21, 2013 at 4:51 AM, Tom Wijsman <TomWij@g.o> wrote:
>
> Well, they are listed there; but it's quite some work to actually go
> through that list, that is, manually check the bugs of ~2000 packages
> as well as file a STABLEREQ bug, takes quite a while...
>
This right here is a real problem.  Any time you're talking about
doing anything on this scale "manually", you've already lost the
battle.  You need a tool to minimise the overhead of time and
cognitive load.  What would that tool look like?  Think about the
steps involved and how you can reduce them to only the parts that
absolutely require decisions on your part.

>> At least in the areas I usually work, I have found a combination of
>> the automatic stabilisation requests and imlate have definitely cut
>> back on the bitrot.
>
> A single unimportant bug can prevent the automatic STABLEREQ bug from
> getting filed; as for imlate, not everyone seems to know that tool, not
> everyone seems to run it. Attention for some stabilizations is lost...
>
First off, why do developers not know about the tools?  How can this
be addressed?  For a start, I'd suggest making sure the tools are at
least mentioned in the docs.  Somewhere other than the amd64 Arch
Testing guide from 2006. [1] That's the only concrete (i.e. actually
in the DOCS rather than the ML archives) documentation I've found so
far, and it only references the file, rather than the tool.  Maybe in
the devmanual Tools Reference? [2]

But, imlate is a good example of a tool that could ease the time cost
of grindy crap.  You showed before that it can get an ordinary count
bounded on n days.  That's handy, but only a little.  Build out:
- How many of those stablereq bugs reference versions no longer in the
tree?  Those can probably get closed.
- How many have newer STABLE versions in the tree in the same slot?
Probably fine to close those, too.
- Of the remaining, how many have patches or ebuilds attached?  Those
may be solved problems waiting for closure; shortlist them.
- How many are packages with newer versions that have been in the tree
for >30 days?  Consider changing the target version, then.
- How many have open blockers, and what are those blockers (w/link and
summary)?  Scan for low-hanging fruit jumping out in that list.
- Get views by category; are there categories where updates are more
important?  Things in @system, and things with security concerns
(stuff in net-*) should probably get higher priority; games...
probably less so.
- Are there bugs with certain keywords in the body that should raise
priority?  Things like "security" or "overflow" might be good
candidates.
- Are there bugs with certain keywords in the body that indicate it'll
be really easy to decide? e.g. "trivial" or "minor" might turn up some
of those super-small version bumps that you pretty much know aren't
going to affect stability.

These are just examples off the top of my head, and by no means
bulletproof, but these are in the class of improvements that have ROI
because they reduce a task that previously took developer time to one
that takes CPU time.  CPU time is essentially free compared to the
value of dev time.

And I'm not saying more recruiting shouldn't happen, but relying on it
is no better than hoping at $deity for bugs to close themselves. ;)

Cheers,
Wyatt

[0] Okay, maybe in the "glory days" when we were higher up on
Distrowatch and thing were really kicking. (I know, I know, "DW isn't
representative", but really? Sabayon is doing better than we are,
now?)
[1] http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1&chap=2
[2] http://devmanual.gentoo.org/tools-reference/index.html