On Tue, Feb 20, 2007 at 03:52:07PM +0000, Ciaran McCreesh wrote: > On Mon, 19 Feb 2007 20:21:49 -0800 Brian Harring <[EMAIL PROTECTED]> > 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
pgpyPtYgJoh6W.pgp
Description: PGP signature
