Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10
Date: Thu, 29 Aug 2013 17:49:44
In Reply to: Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10 by "Andreas K. Huettel"
1 On Thu, Aug 29, 2013 at 12:06 PM, Andreas K. Huettel
2 <dilfridge@g.o> wrote:
3 >
4 > Sounds reasonable, but then you get just abused by Mr_Bones for breaking the
5 > deptree.
7 The solution to that is to either ignore the abuse, or drop the stable
8 keywords on all reverse deps as well.
10 Dropping individual package keywords shouldn't happen much, since the
11 fact that it is happening is a good sign that the whole arch should be
12 dropped. If an arch team can't keep up with a single package they
13 should remove the stable keywords themselves so that this can be done
14 in an orderly manner.
16 >
17 > Anyway, how about when the arch has not even responded to the (much older)
18 > KEYWORDREQ for that package? :|
20 I see this as less of an issue - maybe the maintainer just drops
21 themselves from the bug to be added-back by the arch team only if
22 needed. If the maintainer logged it they can also cancel it if they
23 don't care to see it open.
25 The only people affected by a pending KEYWORDREQ are the users of that
26 arch. They're at the mercy of the arch team no matter what - if the
27 package matters that much to them they should step up to arch test.
29 Please don't interpret anything I'm saying as a lack of care for small
30 archs. I'd just rather see them define their goals in terms of things
31 they can actually accomplish and then accomplish those. Having a
32 bunch of ancient stable versions that are just weighing down the rest
33 of the distro isn't really a good measure of success. That was why I
34 suggested the possible @system-only compromise - it might be a way to
35 capture some of the value of having stable keywords while greatly
36 reducing the amount of work involved. Better to do less but do it
37 properly.
39 That said, I'd also encourage maintainers to leave around old versions
40 as long as they aren't actually maintenance burdens. If they become
41 such, well, time to prune if the STABLEREQ is stale.
43 Rich