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

[Travis Tilley]

On Saturday 19 June 2004 11:21 am, foser wrote:
> 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.

well most maintainers are on x86, no? i was venting valid frustrations here.

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

-* is the only way to add an ebuild for testing without forcing it on ~arch 
users. i still have -* in keywords for the convenience of x86 users who want 
to test and port x86 software to gcc 3.4 (and submit patches on bugzilla) by 
simply adding "sys-devel/gcc -*" to package.keywords.

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

i didnt break binutils or commit the ebuild that was wonky. i simply noticed 
and used -* to mask it... since they contained fixes for uclibc users and 
only worked for them. as for the gcc mistake, everything worked for me with 
that release until i tried to compile a kernel. and yes, this was when the 
ebuild was still -*. and yes, it was necessary to have it in the tree for 
testing/porting help from other devs/users, without which i would have had a 
lot more headaches fixing stuff up for gcc 3.4. as for glibc, like i said... 
it passed "make check" as long as i didnt use portage to do it. i found out 
that this was a sandbox problem that for some reason didnt stop the tests... 
this wasnt me using ~arch for testing in the live tree, it already passed all 
testing and i was just a tad bit confused.

do i really need to defend myself here? if you think i shouldnt have cvs 
access, feel free to let the right people know. i'm already suspended for 
snapping at you. to quote another dev (anonymously) "we've been wanting to 
tell foser that for a long time", so i'm assuming you've been pissing off 
mips devs too. perhaps we should all have our cvs access removed :)

> 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 love how this is changing from the topic to explaining how little faith you 
have in me here. yes, i mentioned it. and i think the maintainer let upstream 
know what version worked and that lead to an upstream fix. go team. :)

you missed the fact entirely that the maintainer's arch is often x86 and this 
makes things difficult for other arch maintainers if it's the arch to judge 
things by.

marking it -arch would be a bad idea, as only that plugin was seriously broken 
and it's mainly an aim client.

the maintainer's arch cant always know about problems... for example, i was 
pretty confident about gcc 3.4 after doing a 3.4 only install on amd64 and 
ppc64 just to realise that this was still not really possible on x86 (at the 
time)... and i only realised this from reading the forums and bugzilla, not 
because some interested x86 dev came to me and said so.

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

if it's the ONLY reason, it is NOT a good reason. if there is another reason 
WHY it hasnt been marked stable, then THAT is the "good reason" for not 
marking it stable on another arch... did you read my argument or are all my 
words pointless to you and not worth your time?

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

i was aware of the issues involved here and thus didnt touch this version on 
my arch until it was stable on x86 for a good while. /then/ i marked it 
stable... you made it very well known that there were problems, as did the 
bug reports on bugzilla. there was a good reason here for not marking it 
stable other than the fact that it wasnt marked stable on the maintainer's 
arch (x86).

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

amd64, ppc64, and mips lately thankyou (well, due to the N32 mips port). i 
cant have an arch-only view when i'm working with the toolchain... perhaps 
you'll need to get rid of all your x86 boxes to see why it might be a bit 
frustrating. i have root on a dual g5, an 18 processor mips box, i have my 
amd64 box for amd64 and some very rare but needed x86 testing... hell, i even 
got yelled at once for making too many glibc snapshots cuz i had to first fix 
something on ppc64 and then to fix nptl on *gasp* x86 since i caught ulrich 
drepper at the start of a series of cvs commits. i'm not just operational 
lead for amd64 you know ;p


-- 

Travis Tilley <lv@g.o>

--
gentoo-dev@g.o mailing list