Re: [gentoo-dev] Xmms needs to die.

[Luis Francisco Araujo <araujo@gentoo.org>]

Alec Warner wrote:
> Paul de Vrieze wrote:
>> On Thursday 24 August 2006 20:46, Alec Warner wrote:
>>> Robert Cernansky wrote:
>>>> What bothers me also, is that it has not plugin design like
>>>> xmms. Support for plugins is very good because lot of people can write
>>>> plugins for lot of things. This is why people do not want to switch
>>>> from xmms because thanks to plugins it have so many features that
>>>> currently no player is able to overcome it.
>>> So port the plugins from xmms to $NEW_CLIENT, since xmms is an old piece
>>> of crap.
>> Who cares. It works (mostly), it is lightweight, and there are enough people 
>> using it to keep it in the tree. As long as things don't break beyond repair 
>> I see no reason whatsoever to remove xmms (or any other largely unmaintained 
>> package in the tree).
>>
>> Paul
>>
> 
> This is one of those things (along with qa and security) that the
> community needs to decide.  Does stuff that works but has terrible qa
> stay in the tree?  Does security stuff stay in the tree, but masked?
> Should xmms be masked?  We have no real way of "deprecating" a package,
> aside from leaving it in the tree with a masking reason saying
> "deprecated and unsupported." at which point not everything in the tree
> becomes supported.
> 
> The Treecleaner project that I run is based on the assumption that
> broken stuff in the tree is bad, and I try to remove the really old stuf
> broken stuff first.  However I aspire to eventually "catch up" and get
> to the currently broken packages.  So which way will you have it?  Or is
> this more of a pragmatic stance on the tree?


Broken stuff but still maintained upstream, mask it.

Broken stuff and unmaintained upstream , send it to the overlay
(probably with a note warning about it on the ebuild?).

I would opt for that.

So, about the xmms ebuild, i agree with sending it to the overlay.

-- 


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


-- 
gentoo-dev@gentoo.org mailing list