Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Date: Tue, 25 Jul 2017 20:12:15
Message-Id: CAGfcS_n39WmeXXFr_XrS-QH_rcWWi3PqcEtVEdx=vkP7GbxsUg@mail.gmail.com
In Reply to: Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? by Markus Meier
1 On Tue, Jul 25, 2017 at 3:45 PM, Markus Meier <maekke@g.o> wrote:
2 > On Tue, 25 Jul 2017 11:03:30 +0200
3 > Agostino Sarubbo <ago@g.o> wrote:
4 >
5 >> On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
6 >> > 1. lack of automation
7 >> I'd summarize the techical steps into:
8 >> 1) get the list of packages
9 >> 2) test
10 >> 3) commit to git
11 >> 4) write on bugzilla
12 >>
13 >> 1 is done by getatoms https://github.com/kensington/bugbot
14 >> 2 is done by the tester in the manner he prefer
15 >> 3 no official tool available, I used a modified version of
16 >> https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py
17 >> which is still based on CVS
18 >> 4 no official tool available, I used my own bash script which calls
19 >> pybugz
20 >>
21 >> So, points 3 and 4 needs to be improved, I have the idea on how the
22 >> script should look, but I have no time to do it and no python
23 >> knowledge. I can assist everyone that candidate itself to make the
24 >> tool/script like I did with kensington when he made getatoms.
25 >
26 > for 3 and 4 there's the keyword.sh script in my overlay (under scripts)
27 > that has been working for ages (at least for me)...
28 >
29
30 It is a slightly different process, but there is also the situation
31 where an arch is slow to respond to a stablereq and the maintainer
32 wishes to drop keywords.
33
34 In that case a script is needed which will remove stable keywords on
35 all reverse deps of the package.
36
37 Back when the council approved dropping keywords in these situations
38 it seemed to be that the effort required to do so was the main barrier
39 to maintainers taking advantage of the policy. Awareness might be
40 another issue, as I don't think it really got documented outside of
41 the summaries.
42
43 --
44 Rich