[gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages

[Tomáš Chvátal]

Hi guys,
as I am now messing around libreo I am meeting a lot packages that
none bothered to stablereq since 2009 or so, the versions in ~ are
cleaner, more up to date, and possibly contain less bugs.

The issue here is that if some part of the tree looses lots of its
maintainers we as devs usually manage to shape it up enough for us in
testing but nobody ever bothers to wait that 30 days and open
stablereq.

So, the issue is obvious, we have packages in testing that are in
better shape than stable ones.

Testing requests for bumps are now handled by euscan +-, cool job for
that website by Iksaf, and I thing we need something similary scanning
the main tree for stables and instead of bugreports the arch
teams would have queue.

How would such thing work?

Well it would be something like priority based queue with maximum 60
points value.
Each update after the month in main tree would get 0 points for
stabilisation, any-developer / maintainer would be able to add up to
40 points to any package and security team members would be able to
add all 60 points. Security team/any developer would also have
possibility to add new packages to queue manualy.
Each user could vote for any package giving out 1 point up to 10
points (eg max voteup for 10 concurent packages).
For each folowing month the package would gain another 10 points,
unless disqualified by qa/maintainer where it has to be off the queue
for 1 month (or disqualified indefinetly based on some version range,
eg beta series is 2.5 so we don't want to stable).
Then arch team would just go and stabilise based up on the queue where
each AT or arch dev could mark it as working. If there are 3 acks from
Arch testers then even maintainer can proceed with the addition of the
keyword not having to wait for arch dev to test the package, reducing
the workload on arch devs (hopefully).

The key problem for whole app is that you need to make sure the queue
is a) properly sorted b) each request has proper depgraph so things
does not break for AT/devs.
This could be achieved by running the script and solving the depgraph
prior creating the request. Example:
We have stable possibility for harfbuzz and libreoffice, libreoffice
depends on harfbuzz.
The application would open just one stablerequest for libreoffice
where it would put everything pulled in by its depgraph including
harfbuzz and no separate request for harfbuzz is opened. If harfbuzz
would not be ready yet for stabilisation then the libreoffice would
not be YET added to the queue untill the harfbuzz passes the 30 days
too.

Here the queue of course have to differ for other arches as sparc have
keyword for harfbuzz but not libreoffice.

So do you thing it is possible to write such web app/ do you know if
anyone would be able to write so? If no I think I have proposal for
next GSoC as mentor :P but I would really like to see it sooner.

Cheers

Tom

PS: no i can't write it, I seriously lack a time for such thing so I
am just trying to find out if anyone is interested to work on it or if
you even thing this is a good idea.