| 1 |
On Wed, 9 Jan 2008 06:58:40 -0800 |
| 2 |
"Alec Warner" <antarus@g.o> wrote: |
| 3 |
> I think the argument here is that developers control ebuilds. If a |
| 4 |
> given ebuild is causing 'trouble' for a maintainer it is within their |
| 5 |
> control to remove the ebuild. Just as if a given package is causing |
| 6 |
> the maintainer grief it can be deleted from the tree, so can keywords |
| 7 |
> for a given arch be removed for a given ebuild (and possibly that |
| 8 |
> ebuild removed because it is known to be old and buggy.) |
| 9 |
> |
| 10 |
> If the arch team wants that ebuild in the tree they should do some |
| 11 |
> work to keep a given package up to date in terms of other arches or we |
| 12 |
> should define some sort of metadata that notifies people that the arch |
| 13 |
> team is the 'maintainer' for a given version of a package. |
| 14 |
|
| 15 |
The problem is this: the impact upon an arch of dekeywording something |
| 16 |
is almost always far higher than the impact of leaving things the way |
| 17 |
they are. And even if, like some people here, you don't care about the |
| 18 |
arch, the impact upon the rest of the tree when you dekeyword is often |
| 19 |
massive. If, for example, an arch were to have their last stable |
| 20 |
keyword of something like gtk+ removed by a developer who did it in |
| 21 |
order to 'fix' a repoman message, a very large number of other |
| 22 |
developers would then end up with a far bigger repoman mess. |
| 23 |
|
| 24 |
Heck, most of the repoman messages people are moaning about are caused |
| 25 |
by developers doing exactly this. |
| 26 |
|
| 27 |
-- |
| 28 |
Ciaran McCreesh |
Archives