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

[foser]

On Sat, 2004-06-19 at 22:46 +0200, Danny van Dyk wrote:
> 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.

No they shall not and as an arch maintainer you don't know how well it
behaves in general now don't you ? What's the logical conclusion from
that fact...

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

What is your point here really..  I've never said that arch maintainers
can't do things different from package maintainers. I even agreed that
in cases of base system stuff it's probably better, but this doesn't
scale at all to all of Gentoo QA wise.

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

If amd64 is such a moving target, then what does it do in the main
tree ? I've asked similar questions before, because I didn't believe it
is the best place to develop unstable new features. If all that it has
brought to us is spreading bad developer practice all over the tree and
even defending it, then I tend to think I was right about my initial
objections.
Oh, I should not have said that, now I'm going to be demonized all the
way. This must've been my big plan behind the scenes all along...

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

I'm not sure what the connection is to live-cd's, releng, etcetera... a
snapshot could be taken at _any_ point from the stable tree and it
should work. What I suggest is only a way to ensure that this will still
be the case in the future, moving stable before the maintainer is
confident about a package is a way to break this.

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

*64 then. My arguments are based solely on my fear that the quality of
Gentoo is declining by certain practices that are now commonplace in the
tree.

>  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 makes me grin that you actually bring this up as a measuring scale.
Someone who fixes all copyright headers makes a lot of commits, but
doesn't add much.

>  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" !

I'm sort of sad to hear that you do not think my point is not meant to
improve Gentoo or at least keep it at the level that it is at.

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

Do I ? I think you pull more into this than I do, I didn't set off this
whole discussion, I just replied with what I think is the right thing to
do.
Anyway, I'm sort of getting targeted by one dev of a certain arch after
another, who often tend to flip out at me personally, while I have been
only on topic so far. So as far as crusading goes, you might want to ask
someone else about the right direction to Jerusalem.

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

Ehm, this is basicly what I've said so far. And this point is when the
maintainers arch goes stable.

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

I really don't see what the difference is with my suggested policy all
along. Only some arches do not adhere to this currently, thats my point.

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

Well, i hope i corrected it enough. But I'm glad you agree with me in
the end. Don't let the pope's propaganda fool ya.

No harm to you,
- foser