On Sun, 2008-01-06 at 23:34 +0000, Ciaran McCreesh wrote: > Ok, so explain: > > * How perpetually open bugs are a maintenance burden. They don't > generate emails and they don't require any work on the maintainer's > part. Is the mere fact that they show up in queries all you're > concerned about, and if so, have you considered either adapting your > queries or requesting a special keyword to make such bugs easier to > filter?
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. > * 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. Now, I know that you're just being your usual self-absorbed argumentative self and I likely shouldn't feed you, but I thought that answering this might clear it up for the people who don't understand this as well as you do. This is especially true since you've been pretty much the main proponent for keeping things as they are with these slack arches. 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. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
