1 |
El dom, 15-09-2013 a las 11:03 -0400, Rich Freeman escribió: |
2 |
[...] |
3 |
> As I see it we really only have two sustainable options: |
4 |
> |
5 |
> 1. Drop stable keywords on these arches wholesale. |
6 |
> 2. Allow maintainers to be more aggressive about dropping stable |
7 |
> packages when bugs are not closed in a reasonable timeframe (say, 90 |
8 |
> days). |
9 |
> |
10 |
> I suspect that #1 may be inevitable for some of these archs, but I'm |
11 |
> certainly willing to try #2 first and see where that leaves us. I |
12 |
> don't like the idea of maintainers having to maintain old versions of |
13 |
> things like gnome because arch teams put in some time in years past |
14 |
> but aren't interested in the newer version/etc. |
15 |
> |
16 |
> So, how about this as a policy: |
17 |
> If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a |
18 |
> pending STABLEREQ, for 90 days with archs CCed and otherwise ready to |
19 |
> be stabilized, the maintainer can remove older stable versions of the |
20 |
> package at their discretion. A package is considered ready to be |
21 |
> stabilized if it has been in the tree for 30 days, and has no known |
22 |
> major flaws on arches that upstream considers supported. |
23 |
> |
24 |
> Note that if upstream doesn't support an arch, then it falls to the |
25 |
> arch team (and not the maintainer) to support that arch if they want |
26 |
> it stable. |
27 |
> |
28 |
> If the problem is limited to particular groups of packages then the |
29 |
> new policy would take care of itself - stable keywords would basically |
30 |
> get dropped until we're down to a set of packages that the arch team |
31 |
> can support. If the problem is more widespread, then the new policy |
32 |
> will basically make stable unusable on that arch as system packages |
33 |
> get dropped, in which case we're basically back to dropping stable |
34 |
> keywords. |
35 |
> |
36 |
> Again, this has nothing to do with picking and choosing arches to |
37 |
> support. This is about defining the responsibility of arch teams if |
38 |
> they want to be considered stable. The stable policy is basically a |
39 |
> contract between arch teams and maintainers, and both sides have to do |
40 |
> their part to make it work. |
41 |
> |
42 |
> Rich |
43 |
> |
44 |
> |
45 |
|
46 |
I guess an important problem is that, once we drop keywords in a |
47 |
package, a cascade effect can appear. For example, if we drop stable |
48 |
keywords of gtk+ and pango due pending keywording, we will need to also |
49 |
drop a ton of packages. And for cases where we would need to drop the |
50 |
keywording completely, the situation can be even more difficult. |
51 |
|
52 |
I remember long time ago HPPA did an important reduce of keywordings in |
53 |
that arch (I remember they lost most gnome2 packages), not sure if maybe |
54 |
other arches could need it too :/ |