Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[Danny van Dyk]

Hi foser,

>>isnt that situation something for -*? when i was ready for gcc 3.4 getting
>>much wider testing than just the very brave and curious i said so by marking
>>it ~amd64 (and then going into the ppc64 and mips channels to announce it to
>>those i thought would need to know. note that it isnt quite ready for general
>>use on x86 at all, which others seem to consider the high holy arch for
>>determining stability/usability... pffft).
>
>
> My initial email tried so hard to not make 'maintainer arch' the same as
> 'x86', then why do you bring that up as a focus point. It is this
> attitude (my arch vs yours) that makes it hard to get any healthy
> discussion going here.

You always talk about the "maintainer arch". With the exception of 
packets that _are supposed_ to work only one special archs (yaboot or 
milo comes to my mind), speaking of a "maintainer arch" is nonsense in 
my eyes. 99% of all packages shall work on every arch, but they 
naturally don't work equally well on them. Best example is (again; Lv 
mentioned it already) gcc-3.4. [Please don't try to tell me there is a 
maintainer arch for gcc !] gcc-3.4 is currently marked stable on amd64, 
*but* is is hardmasked in case you haven't switched your profile over to 
gcc34-amd64-2004.1, so no user who doesn't want to get's tampered with 
gcc-3.4 problems. And you know what ? Our users rushed out to switch 
profiles less than 5 minutes after Lv announced this solution on 
#gentoo-amd64. Why ? They were not confident with the way gcc-3.3* works 
  on amd64. There are plenty of things gcc-3.3 lacks, starting with a 
missing "-march=[k8, amd64]" up to severe miscompilation on all kind of 
code when using "-Os" or "-O3".


>>when i knew that the binutils ebuilds were kinda wonky and not working right,
>>i ripped them out of ~arch and popped them into -*. when i made a mistake
>>with gcc and SSP, i had a new release out within minutes of figuring it out.
>>when i found out that glibc 2.3.4.20040605 was failing makecheck inside the
>>ebuild but succeeding outside of it, i marked it -* until i figured out
>>why... that glibc ebuild is now stable on ppc64 (pretty early... committed
>>june 05, stable june 12) and i'm pretty excited about that. it didnt go into
>>ppc64 stable while -*, and testing shows it fixes the segfaults that happen
>>on that arch. you'll have to ask tom gall, but it may be the first release to
>>pass "make check" on ppc64. :) using gcc 3.4 no less, with altivec fixes. :)
>
>
> -* means broken on all arches by definition. Sure it's a pretty good
> solution here for what you want to do, but it still is bending the
> rules.
>
> What i see from your developers tale here, is that you do your testing
> in the live tree. I mean serious.. messing libtool, gcc & glibc and
> being happy with that ? I'd say that stuff should've been done in
> package.mask, certainly not in ~arch. One used to get his cvs access
> rights under discussion after these kind of things.

amd64 is a moving target, it's a relative new arch that does not run w/o 
any problems, but it runs really good for day to day work and there are 
even people who use Gentoo/amd64 on production systems. Lv and many 
others (including me) try to keep this arch stable and to improve things 
in the best way we can. Honestly, I really get annoyed when you 
critisise our efforts w/o any insight in our daily work. Your examples
libtool, gcc and glibc *ALL* had severe problems that _all_ improved 
after switching to new versions, yes even by marking prereleases/cvs 
snapshots and development versions _stable if necessary_.

>>and in other news, i got a bug for all arch maintainers to mark a version of
>>gaim stable that was stable on x86. i flatly refused, as the yahoo plugin
>>didnt work at all on 64bit archs (like the version i had in stable did)...
>>when it finally did work, i marked it stable. so much for x86 being a
>>measuring stick of any kind...
>
>
> Well, i assume the yahoo plugin worked on x86 at that point. 'x86' here
> being the 'maintainers arch' i assume, it was ready for going stable.
> Next 64bits arch weren't stable, so you did the right thing not marking
> it as such. 'x86' again is mentioned here, it's irrelevant which
> platform is the 'maintainers arch', don't get so hang up on x86. It is a
> measuring stick that the _ebuild_ & _package_ were tested at that time.
> I wonder if they even were aware of the 64bit platform problems, if so
> they should've probably pushed to 64 bit teams to mark it -<arch> for
> their respective platforms (known not to work). See, the 'maintainers
> arch' should know about _all_ problems with the packages. If you were
> aware of it & failed to inform them, then this is really your mistake
> showing.
>

"'the maintainer's arch' should know about _all_ problems with the 
packages."... Well, okay... screw the whole gentoo structure, we only 
need one releng-dev to build all arch-livecds and the package 
maintainers... I hope you recognized my sarcasm. I really hope so.

> [snip]

> Your arguments tend to be emotional and really based on an arch vs arch
> attitude, not willing to take into account serious QA problems in your
> 'solutions'. See it in the bigger picture of Gentoo overall quality for
> once, not your shortsighted amd64 only vision.

On the contraty, in my point of view your arguments seem based on the 
fear to break/to question hierarchical structures. And please don't call 
Lv's vision "shortshighted amd64 only". He's been working to improve the 
toolchains not only of amd64, but also from mips (with 3 ABIs) and 
ppc64. You are continously trying to talk bad Lv's efforts. Last month 
he did 111 commits, you did 50, this month he did 166 commits, you did 
6. It's naturally that with more commits there sneak in more errors. In 
my eyes, you should try to take up a bit of Lv's vision. His "vision" is 
to improve Gentoo. Please don't call that "shortsighted" !

Foser: this *no battle* between amd64 and x86, and this is especially 
*no crusade* against you (or the gnome-herd). But you try hard to let it 
look that way.

--

IMHO the above comments had to be said, everything's been comments on 
foser's statement. However, I'd like state something to the 
"stabilization" process on my own, too. We urgently need a policy on 
this, and i want to suggest a system where the ebuild maintainers as 
well as the arch developers both get actively get involved.

1. The ebuild maintainers should have the possibility to say: "ARCHs, 
feel free to mark stable. All major bugs that i know of are closed, only
arch dependent bugs are left."

2. The arch maintainers should ask the package maintainers first before 
marking a package stable *before* the maintainer's approval. However, 
there are package maintainers that aren't on IRC all the time/that check 
  their dev-mails regularly, but probably only once or twice a week. In 
this case, arch maintainers should be allowed to just check bugs.g.o on 
major bugs and mark stable if the arch decides so.

This is pretty much the way Donnie Berkholz proposed (Please correct me 
if I'm wrong), and in my eyes it's the only way that makes sense.


--
gentoo-dev@g.o mailing list