On Tue, 20 Feb 2007 01:35:32 +
Ciaran McCreesh [EMAIL PROTECTED] 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.
snip
Wow, I almost don't know where to begin. The amount of FUD,
misinformation, and outright lies floating around all of this bullshit
is astounding. If you believe everything you've read from some
incessantly obsessive blogger and some extremely loud and misinformed
bug wrangler, you would believe that the mips team killed the baby
jesus, caused the plagues, invaded Europe, and invaded Iraq...all with
me as their supreme dictator. And yes, to you so impaired, that was
indeed sarcasm. It seems like many of you are under some sort of
warped impression that *I* am actively trying to hold back the tree,
with my sole reason to piss of ebuild maintainers. That is so
incredibly far from the truth as to be completely insane. So, let's try
to clear some of this up, shall we?
First of all, to you vivo, before you say something else you might
regret later, you should consider that mips *has* gotten help recently,
and said help is doing a very good job. The situation is only
improving. More on this later. And also, it is *not* my fault that
Diego quit. But if you want to keep loudly whining on the mailing list
here about how I'm still around (I'm not actually) and Diego is gone,
keep on going. More on this later too. You can say whatever you want
about me, I actually have thick skin, unlike certain other people,
however you are not making the situation any better. I suggest you
stop.
To t3h Harring and Mr. Parallel Grapefruit, I agree with you, Lies,
Damn Lies, and Statistics. Citing percentages is circling around the
point that Ciaran made. Some arch could only have 10 packages
keyworded out of the entire tree, with 3 of them being slackers as
defined here. This arch would lead your list by a wide margin. The
fact is, tree bloat is measured purely by the *absolute number* of
packages which are behind another arch.
All of that said, how about we clear up all of the misinformation about
how arch keywording really works, how deps get wrongly dropped, and then
explain why mips has generally fallen behind. This isn't an excuse,
but is merely a statement of facts which describe the situation.
First, the ~arch tree. This one is easy. In most cases, you can
merely compile test something against the ~arch tree, and then do a
fairly quick run test to make sure things seem to be working as they
should. If additional deps are required, they must be similarly
tested. Another rule of thumb is that if other arches already have
~arch keywords and there have been no bugs saying something like this
is complete crap and shouldn't be in the tree, then you can have
fairly good assurance that you haven't missed any critical bugs (aside
from really really wacky arch specific stuff...more on this later).
Furthermore, ebuild maintainers are allowed (and encouraged) to carry
~arch keywords forward during version bumps.
How about the stable arch tree? This one is
trickier. In order to bump an ebuild into the stable tree, the arch
team has to be far more careful. Not only must this ebuild have been
in ~arch for 30 days without any bug reports, but it must have been
*extensively* tested against the current stable tree to ensure no
breakages. Furthermore, all required deps of said ebuild which are
also ~arch must be similarly tested. This is extremely tedious work
that requires a lot of time, both machine and developer. For those
arches where the best possible supported machines might be on par with
a pentium2 300mhz box, the machine time becomes almost ridiculous.
Now, consider the mips arch. As I insinuated above, the fastest of our
supported machines really isn't a speed demon. However, there is even
*more* complexity with mips. We support both big endian *and* little
endian configurations across *multiple* ABIs. This makes testing even
more difficult and tedious. I can only speak for myself, but I always
strived to make sure anything I ever keyworded worked on *both* our
standard 32-bit ABI, and the more experimental n32 (for simplicity, it
is a quasi 64-bit ABI with a lot of funkiness). The compile time
required for all this testing is ridiculous. It might take two weeks
or longer to get something very large compiled (accounting for compile
failures and other unforeseen stuff) on the machines I had available.
Other developers are similarly constrained by the speed of their
machines. Again, not an excuse, but just a fact of how things are. If
I had infinite time to work on Gentoo, this would not be an issue.
I fully admit that for pretty much the entire past year, I have not had
time to do any of this, so I have slacked, and is the reason that I
have ultimately retired. It seems like time constraints have similarly
affected the rest of
