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

[foser]

On Fri, 2004-06-18 at 17:08 -0400, Travis Tilley wrote:
> > Sometimes it is the case that because of the state of the package or the
> > ebuild (missing features) you don't want to make a certain ebuild stable at
> > all. Or that you know that it could create problems not directly related to
> > the ebuild being bad. In any case from a maintainer viewpoint is is quite
> > anoying to have your judgement challenged under your fingers.
>
> 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.

> 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.

> 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.

> i dont think i want someone on another arch telling me what i can and cant
> mark stable unless there's a good reason behind it. "i havent marked this as
> stable yet on my arch" is -not- a good reason... especially with gcc 3.4
> needed for an n32 mips port (c++ wont compile at all without it apparently),
> and so many apps in testing (not -*) with gcc 3.4 fixes that certainly work
> better than "not at all, period" (i mean, i HAVE been working on gcc 3.4
> fixes in the tree since before it was released. before i even put the ebuild
> in the tree on apr 19th). or ppc64 needing the same for altivec fixes and
> getting away from having to use hammer-branch cvs snapshots. or amd64 needing
> the same... amd64 fixes and proper arch support (for example, we JUST got an
> -march= option) and because some kernels just miscompile with 3.3.3 on amd64.

Actually 'i haven't marked this as stable yet on my arch' is a good
reason if the ebuild maintainer tells you so, for the simple reason that
you lack the overview over the full package maintenance outside the
scope of your arch. I cannot believe how you can so easily disregard
this form of basic QA.

As an example of it can go wrong, there was an arch that marked gtk+-2.4
stable before the maintainers arch & effectively broke the building of
over a dozen packages in the tree. The maintainers were keeping it in
~arch to get those issues fixed, but with their QA hurting ways the arch
got their users into trouble for no reason whatsoever. In smaller ways
this has happened numerous times now with different arches doing it.

> BAH. and DOUBLE bah. ok, i'm done ranting :) hope it isnt too bad of a rant...
> ^^;

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.

- foser