Re: [gentoo-dev] Slacker archs

[Brian Harring]

On Tue, Feb 20, 2007 at 03:52:07PM +0000, Ciaran McCreesh wrote:
> On Mon, 19 Feb 2007 20:21:49 -0800 Brian Harring <ferringb@×××××.com>
> wrote:
> | On Tue, Feb 20, 2007 at 01:35:32AM +0000, Ciaran McCreesh wrote:
> | > It is widely perceived that Gentoo has a huge problem with slacker
> | > archs cluttering up the tree and making maintainers' work harder.
> | > Clearly, something needs to be done about this.
> | >
> | > I think the first step is to establish what all the problem
> | > architectures are. We all know that mips is by far the worst
> | > offender, but by how much? Rather than speculating wildly, I
> | > decided to make use of adjutrix and wc to find out. So, here we
> | > have a table showing just how much mips is a slacker arch:
> |
> | Lies, Damn Lies, and Statistics.
>
> Exactly my point.
>
> | > As expected, supporting minority archs is leading to tree-wide bloat
> | > and huge initial rsync times for users. Clearly something has to be
> | > done to protect Gentoo from those useless minority archs! I mean,
> | > how many users do we *really* have using amd64 or x86?
> |
> | Actually digging into the data rather then doing the "lies, damn
> | lies, and statistics" approach shows a pattern of mips having a large
> | % of their stable packages lagging the others.
>
> Which isn't at all relevant when it comes to the question of causing
> tree bloat.

Tree bloat is commonly defined as crap packages hanging around, crap 
versions.

Arches trailing behind in stabling means that their *are* older 
versions that can't be punted, which frankly, is inducing 'tree 
bloat'.

Regardless, data was presented as "see, mips isn't behind"; which... 
isn't the case as your own data shows.

~harring