Gentoo Archives: gentoo-project

From: William Hubbs <williamh@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items
Date: Sun, 05 Apr 2015 19:50:53
Message-Id: 20150405195044.GA2917@linux1
In Reply to: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items by Pacho Ramos
1 On Sun, Apr 05, 2015 at 02:32:27PM +0200, Pacho Ramos wrote:
2 > El sáb, 04-04-2015 a las 17:02 -0500, William Hubbs escribió:
3 > > On Sat, Apr 04, 2015 at 11:13:54AM -0400, Rich Freeman wrote:
4 > > > On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@g.o> wrote:
5 > > > > On 04/04/15 07:13, Andreas K. Huettel wrote:
6 > > > >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
7 > > > >>
8 > > > >>> For reference, the policy we came up with last time for ia64 and alpha only was:
9 > > > >>
10 > > > >>> "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
11 > > > >>> pending STABLEREQ, for 90 days with archs CCed and otherwise ready
12 > > > >>> to be stabilized, the maintainer can remove older stable versions of
13 > > > >>> the package at their discretion. A package is considered ready to be
14 > > > >>> stabilized if it has been in the tree for 30 days, and has no known
15 > > > >>> major flaws on arches that upstream considers supported."
16 > > > >>
17 > > > >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
18 > > > >
19 > > > > I am against breaking the deptree for any arch that has a stable
20 > > > > profile. It's reasonable to expect devs to dekeyword revdeps to ensure
21 > > > > the deptree is consistent.
22 > > > > If the state of the arch really is that bad, its profiles should be
23 > > > > switched to dev or exp to reflect reality.
24 > > > >
25 > > >
26 > > > Tend to agree, but be careful what you ask for. Which would the arch
27 > > > team REALLY prefer after ignoring a bug for 90 days? The stable
28 > > > depgraph is broken and they have to hurry and stabilize one package to
29 > > > fix it, OR the stable depgraph is fine, but suddenly 300 packages no
30 > > > longer have stable keywords at all. Fixing the latter would be a
31 > > > royal PITA without git. Getting rid of stable on those 300 packages
32 > > > is also a lot of work for the package maintainer without some kind of
33 > > > tool to automate this.
34 > >
35 > > I agree. I think the temporary stable depgraph breakage is the lesser of
36 > > the two evils in this case. Also, I would add that, once an arch team
37 > > starts getting hit with enough deptree breakage they should be able to
38 > > make the decision to revert their profiles to dev or exp without council
39 > > intervention.
40 > >
41 > > William
42 > >
43 >
44 > I wonder if maybe we should suggest to finally move ia64/alpha/sparc to
45 > testing (as was done for mips, sh...) :/
46
47 Also let's add ppc and ppc64 to this list; they were brought up in the
48 message starting this discussion. I personally would vote for moving all
49 of these arch's to exp status.
50
51 That becomes a separate action and does not answer the underlying
52 question that keeps coming up.
53
54 That question is, if a maintainer opens a stable request and assigns an
55 arch team to it, and that arch team has no activity on the stable
56 request for 90 days, what should the maintainer do?
57
58 I would say that the maintainer can at their discression remove the
59 old stable version. Yes, that would temporarily break the stable
60 depgraph, but it could be argued that the old version is by definition
61 broken since the newer version the maintainer wants stabilized could
62 have fixes for bugs in the old version.
63
64 William

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies