1 |
On Thu, 2004-08-26 at 16:04 +0100, Ciaran McCreesh wrote: |
2 |
> On Thu, 26 Aug 2004 16:51:43 +0200 Carsten Lohrke <carlo@g.o> |
3 |
> wrote: |
4 |
> | From a package maintainer perspective, I'm not fine with it. Imho an |
5 |
> | arch should simply not go stable, before the package maintainer marks |
6 |
> | his arch stable. I cannot care for arch maintainers - and their users |
7 |
> | - if they run into problems, e.g. due to dependency changes while I do |
8 |
> | not consider the ebuild stable. If the arch maintainer thinks, he |
9 |
> | knows a package better than me and cannot even ask before doing so - |
10 |
> | o.k., not my problem. We had the discussion a while back... |
11 |
> |
12 |
> Personally I prefer my original wording: |
13 |
> |
14 |
> > Arch teams: when moving from ~arch to arch on an actively maintained |
15 |
> > package where you're going ahead of the maintainer's arch, it's best |
16 |
> > to consult first. You don't necessarily have to follow the |
17 |
> > maintainer's advice, but at least listen to what they have to say. |
18 |
|
19 |
It's basically the same thing as carlo said, only covered in a nice |
20 |
sauce of political correctness. It's pretty simple, without a real good |
21 |
reason an arch should never go beyond the maintainers arch & never |
22 |
without checking back with the maintaining herd even. |
23 |
|
24 |
So, your 'original wording' is no policy at all, it's just trying to |
25 |
give a wrong sense of QA which is completely lacking from it & is just |
26 |
trying to maintain the status-quo you enjoy at this point. |
27 |
|
28 |
- foser |