1 |
On Sunday 04 September 2005 03:59 pm, Ciaran McCreesh wrote: |
2 |
> On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert <stuart@g.o> |
3 |
> |
4 |
> wrote: |
5 |
> | > Arch teams need to be allowed to override maintainers where |
6 |
> | > appropriate, |
7 |
> | |
8 |
> | Why not talk to the package maintainers instead, and convince them |
9 |
> | that you need a different version marking "maint" instead? Why |
10 |
> | "override" (which, tbh, smacks of "we arch teams know best, life would |
11 |
> | be better without package maintainers") when you could work with |
12 |
> | people instead? You're *not* in competition with package |
13 |
> | maintainers. We're all supposed to be working towards the same |
14 |
> | thing :) |
15 |
> |
16 |
> Sure, we do that anyway. However, sometimes package maintainers are |
17 |
> outright wrong. |
18 |
> |
19 |
|
20 |
agreed talk/communcation is fine, if the maintainer is only trying to flex |
21 |
muscles and does not have a good reason, the arch team ought to be able to do |
22 |
what is best for gentoo and not be shot down by a (hm) stubborn(?) |
23 |
maintainer, if the maintaner could do that, the arch team would be quite |
24 |
limited in its effectiveness |
25 |
|
26 |
> | I've no personal problem with arch teams sometimes needing to do their |
27 |
> | own thing, provided it's confined to a specific class of package. |
28 |
> | Outside of the core packages required to boot & maintain a platform, |
29 |
> | when is there ever a need for arch maintainers to decide that they |
30 |
> | know better than package maintainers? |
31 |
> |
32 |
> Pretty regularly. A significant number of package maintainers have a |
33 |
> very shoddy attitude towards QA, and a significant number of upstreams |
34 |
> have no clue what portability is. |
35 |
> |
36 |
> | If this isn't confined - if arch maintainers are allowed to override |
37 |
> | package maintainers wherever they want to - then arch teams need to |
38 |
> | take on the support burden. Fair's fair - if it's the arch team |
39 |
> | creating the support, it's only fair that they support users in these |
40 |
> | cases. It's completely unfair - and unrealistic - to expect a |
41 |
> | package maintainer to support a package he/she thinks isn't fit to be |
42 |
> | stable on an arch that he/she probably doesn't use anyway. In such a |
43 |
> | conflict of egos, the real losers remain our users. |
44 |
> |
45 |
> If it isn't fit to be marked stable, it shouldn't be out of |
46 |
> package.mask. ~arch means "candidate for going stable after more |
47 |
> testing", not "might work". |