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