Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

[Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

On Tue, 08 Jan 2008 14:04:49 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> I have foo 1.0, which is mips.  There is foo 2.0, which is stable
> everywhere else.  The foo 1.0 ebuild does not conform to current
> ebuild standards.  I want to commit changes to foo 2.0, and repoman
> won't allow me due to problems in foo 1.0, but I don't want to WASTE
> MY TIME on foo 1.0, because it's been EOL for 2 years and I've had an
> open bug for mips to test the newer version for 2 years.  I've asked
> several mips team developers, who all give me the same "we don't have
> enough manpower/horsepower to test that right now" excuse.

You know what by far the largest cause of repoman not allowing you to
commit because of older versions is? Developers screwing up keywords
because they don't care about certain archs. Things don't mysteriously
break on their own...

> > * How unmaintained ebuilds are a maintenance burden. Doesn't that
> > contradict itself?
> 
> When repoman keeps me from being able to commit due to an ebuild that
> remains in the tree only for an architecture hardly anyone uses or
> cares about, that affects me.

And why does repoman do that?

Oh. Yeah. Because people with an attitude like yours think that the
correct way to fix a repoman message is to start nuking arch keywords,
ignoring what it does to the rest of the tree.

> This is especially true since you've been pretty much the main
> proponent for keeping things as they are with these slack arches.

Perhaps because the people maintaining those archs have better things
to do that deal with the same silly ill-thought-out arguments every
three months.

> I mean, if vapier can maintain arm/sh/s390, by himself, to a better
> degree than the mips *TEAM* can do, that should be an indication of a
> problem.

That's an interesting assertion. Can you back it up?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]