Bugzilla Bug 176256

app-emulation/vice-1.21 was version bumped directly to stable on the same
architectures as vice-1.20, and all the previous versions were removed.
i approached nyhm with the issue and he basically refused to correct this by
the usual means (restoring old stable, going back to ~arch on the new one and
calling arches to test).
since nyhm is a new dev i approached his mentor (mr_bones_) and he basically
said he's ok with what nyhm did and just kept silent there on.
at the same time and after this chat i was building vice-1.21 to see if it
works and it doesn't even build, build log is here:
http://dev.gentoo.org/~gustavoz/vice-1.21-sparc-build.log

Created an attachment (id=117414) [edit]
#gentoo-dev IRC log about the issue

Worth mentioning is i usually like solving things by talking directly to people
rather than resorting to QA or devrel and this is a first for me since
responsible people didn't acknowledge this was an issue or that they were at
fault.
Also nyhm didn't do proper ChangeLog entries when removing old versions.

Games.

Games policy.  That's the way we do it.  If there's a bug with vice
specifically, please file a bug about it.  Thanks.

Nah.

The developer handbook states that if you cannot test a package on a given
architecture, you should NEVER mark it stable.  This is documented at
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap3

Additionally, this is in violation of the stablization rules for SPARC as
documented at
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap4

Adding ombudsman for their tracking at this point.

(In reply to comment #4)
> Games policy.  That's the way we do it.  If there's a bug with vice
> specifically, please file a bug about it.  Thanks.
> 

Has this ever been blessed by anyone else than the games team?

I would assume that the games team has always operated on their own like this
and I haven't heard of it being a big problem before. Why would it be a problem
now?

Well, if games can then why can't security do it too? I mean, it would be a
higher priority wouldn't it? Then if they both could, why couldn't gnome and
kde do? And then everyone else.</IRONIC>
By allowing one herd to break QA it sets a precedent for others to do so.
And then the arch teams would be almost like dumpsters for users to dump their
bugs on because nothing is tested and stuff doesn't work.
If that's where this is heading then i can just resign and be over with it.

One exception to the rule has not caused the sky to fall so far, so I don't
think it is to likely to fall in the near future. However if the games guys
could explain why they are so special (other than this is how it is) I would
appreciate it.

The sky is falling more often than you know, in the past we just spoke with
guys who did similar stuff (usually just carrying over stable keywords in
version bumps) and they fixed it. We didn't see fit to make any formal
complains in those cases.

(In reply to comment #11)
> One exception to the rule has not caused the sky to fall so far, so I don't
> think it is to likely to fall in the near future. However if the games guys
> could explain why they are so special (other than this is how it is) I would
> appreciate it.
> 
If it's one exception, then it's just an oversight violation of policy, I
suppose.  If, however, it's game's policy, then there is a direct QA conflict,
because general policy (and specifically sparc policy) explicitly prohibit
this.  (QA comes in if games say "we do this" and sparc says "don't ever do
this".)

For the record now, if this makes it to devrel (which we all hope it doesn't),
I cannot handle it because I have a conflict of interest (I am a sparc
developer).  I am CC devrel to put that on record.  This is not a devrel bug.

(In reply to comment #13)
> If it's one exception, then it's just an oversight violation of policy, I
> suppose.  If, however, it's game's policy, then there is a direct QA conflict,...

i cannot speak for "sparc", but i've seen games packages bumped straight to
"x86" several times, and i know that the games team doesn't have an arrangement
with the x86-team. the last one from the "x86" team i remember, that seriously
tried to do something against that, was Halcy0n and unfortunately he wasn't
very successful. a package where new versions are bumped straight to stable on
"amd64 ppc ppc64 sparc x86" quite regularly is for example
"games-strategy/wesnoth". to cut a long story short: i don't think that doing
occasional straight to stable bumps is games policy, as i've seen at least a
few stable requests for game packages, but it seems to be mr_bones policy.

In x86, bug 176522 which is a regression from vice-1.20 is a fine example why
stable bumps are bad.

In regards to this issue with vice, the bug is stated as being on x86. If that
is really the only architecture with the bug then quick stabilization of
vice-1.21 is only needed. vice-1.20 was marked stable on ppc and sparc so imho
it would have been reasonable to leave vice-1.20 in for ppc and sparc (perhaps
even set it back to ~x86) while stabilizing vice-1.21 only on x86. Then the bug
would be fixed and not stomp on the feet of the arch teams, everyone's happy!

So, could someone give a complete answer as to why games operates the way it
does so we can bring some resolution to this issue?

(In reply to comment #16)
> In regards to this issue with vice, the bug is stated as being on x86. If that
> is really the only architecture with the bug then quick stabilization of
> vice-1.21 is only needed. 

^^ needed on x86 that is

OK.  I've been trying to avoid this, but the constant assumption that all of
games works this way has really gotten to me.  Please be sure what you're
talking about.  At least I know that I follow regular policy wrt games (and
all) ebuilds.

The games team has no policy that I am aware of that says direct-to-stable is
alright.  I know that this *has* been previous practice from the games team,
but I never knew it to be any sort of "policy" or I'd likely have gotten in
trouble for breaking it.  ;]

So, if the simple solution here is to bring back 1.20 and revert the KEYWORDS
for sparc/ppc on 1.21, what's the big deal?  Why in the world are people asking
the Council to do essentially nothing (reiterating policy isn't our job)
because of this game?  Can we not just fix the problem and be done with it?  If
QA thinks there is a problem with the way that certain developers are doing
things, then QA needs to bring that up with said developers, and if necessary,
take the appropriate actions.

Again, don't link everyone on a team with infractions if everyone is not doing
it.  It is simply unfair and has even lead to developers being suspended in the
past.  Let's try to stick to the facts.  Thanks...

(In reply to comment #18)
> OK.  I've been trying to avoid this, but the constant assumption that all of
> games works this way has really gotten to me.  Please be sure what you're
> talking about.  At least I know that I follow regular policy wrt games (and
> all) ebuilds.

Thanks for replying and clearing things up a bit. :-)

> 
> The games team has no policy that I am aware of that says direct-to-stable is
> alright.  I know that this *has* been previous practice from the games team,
> but I never knew it to be any sort of "policy" or I'd likely have gotten in
> trouble for breaking it.  ;]
> 
> So, if the simple solution here is to bring back 1.20 and revert the KEYWORDS
> for sparc/ppc on 1.21, what's the big deal?  Why in the world are people asking
> the Council to do essentially nothing (reiterating policy isn't our job)
> because of this game?  Can we not just fix the problem and be done with it?   

This really isn't a big deal, I just wanted to get a full story of what is
going on.

>If
> QA thinks there is a problem with the way that certain developers are doing
> things, then QA needs to bring that up with said developers, and if necessary,
> take the appropriate actions.

/me nudges mr_bones_ and nyhm

Do you guys have any objection to going along with QA's request and in the
future avoid bumping directly to stable unless it is really necessary? Letting
things stew in ~arch while waiting for an arch team to test it isn't a hard
thing to do and it keeps everyone happy. :-)

(In reply to comment #18)
> OK.  I've been trying to avoid this, but the constant assumption that all of
> games works this way has really gotten to me.  Please be sure what you're
> talking about.  At least I know that I follow regular policy wrt games (and
> all) ebuilds.

And you don't think that comment 3 and comment 4 can be understood this way?

> 
> So, if the simple solution here is to bring back 1.20 and revert the KEYWORDS
> for sparc/ppc on 1.21, what's the big deal?  Why in the world are people asking
> the Council to do essentially nothing (reiterating policy isn't our job)
> because of this game?  Can we not just fix the problem and be done with it? 

I mainly asked because no QA member has commented on this issue so far. The
council intervened with the versioning thing so why not here too to prevent
further breakage.

> 
> Again, don't link everyone on a team with infractions if everyone is not doing
> it.  It is simply unfair and has even lead to developers being suspended in the
> past.  Let's try to stick to the facts.  Thanks...
> 

The facts are here in this bug.

Also if the games team doesn't want their ebuilds to spent the usual month in
~arch, they can just file stable request bugs sooner. Then it's up to the arch
teams on how fast they want to do their keywording.

the straight to stable thing is generally something has always been done with
games ... it was historically blessed (and done) by myself

dont pick out anyone on the games team for this violation as it all just
funneled up to myself and i said our guys could continue to do it if they so
wanted (and some did)

as for arch teams, i stated the situation back before the policy was written
down and when the arch teams were first forming and before this bug, there
hasnt been any direct communication with myself (maybe Weeve dropped a line or
two, but nothing really pursued)

new guys on the x86 team claiming they're unaware of anything ... well not my
problem that you havent been around long enough to be aware of the situation

there has yet to be any real fallout of us doing this, but if the arch teams
are going to get in such a bunch over *games*, then they have documentation on
their side in the argument

games members who dont want to deal with this, we'll just put things in ~arch
and not waste time filing stabilization requests; leave it to users/arch teams
to do it

also, the comparison to security/kde/gnome/etc... is hardly comparable

broken package pushed to stable by security: people cant boot; services are
unreachable; etc... which is hardly acceptable

broken package pushed to stable by kde/gnome: people cant log in and use their
desktop which prevents any usage of their Gentoo system without recovery

broken package pushed to stable by games: people cant load a game (oh no) which
is us denying people the ability to log onto a server and shoot some people ?

If it's in the tree, it should be held to the same QA standards as everything
else.

(In reply to comment #23)
> 
> broken package pushed to stable by games: people cant load a game (oh no) which
> is us denying people the ability to log onto a server and shoot some people ?
> 

Same argument could be used for a lot of packages.

For me this bug is about playing fair and in a civilized way.
I've asked the offending devs to reinstante the working ebuild because no
matter what you say it still doesn't work even on x86 (bug #176522).
So in a peer sense (or professional if you will) their good will is nil.
With that in mind i or any other dev could just ignore mr_bones request to get
the DEPs/masks fixed for stuff that usually breaks (be it accidental, on
purpose, mindless commit or whatever) since basically "you don't fix your shit,
i won't fix mine" right? And then it may not be such an important DEP so why
would i care?
For instance you (spanky) broke libkudzu deps by removing the only stable
>=sys-apps/pciutils-2.2.4 for sparc, mr_bones knew about it and probably one
(or both) of you did nothing, i had to fix your shit.
So is it gonna be like this?

let's review shall we ... i said the games team will start committing into
unstable ... what exactly else do you want done hmm ?

> For instance you (spanky) broke libkudzu deps by removing the only stable
> >=sys-apps/pciutils-2.2.4 for sparc, mr_bones knew about it and probably one
> (or both) of you did nothing,

by the time i heard of the bug it'd already been taken care of ... what would
you like me to do ?  write out a 1000-word essay about how i'm sorry and send
it out to the -dev list ?  monitor every communication channel out there 24/7 ?

> i had to fix your shit.
> So is it gonna be like this?

so first you want us to be "civilized" and then you turn around and make
statements like this ?  how exactly do you want me to take that ?  outline it
for me

Maybe my english isn't as polished as yours, but it doesn't sound as a clear
policy to me that some games devs won't do this any more from the text you
wrote.
And by "fixing your shit" i mean on one side many days passed by until i
decided to fix the pciutils b0rkage (after mr_bones knew it was you), so i
basically dunno if he didn't tell you because of a conflict of some sort (being
pals, same herd, whatever, i really don't care) or you just didn't care about
it. If it's the latter then maybe one day i'll stop caring about fixing sparc
stuff devs request and just let things rot to hell.

Adding to the last comment i made "so hey, if devs don't care about my shit why
would i care about theirs!" (if you don't like the term shit here it's nicely
applied to myself).

there's no sense in pointing fingers here ... Mr Bones has nothing to do with
it, assume that 1 second after he found the issue he told me and i ignored it,
it doesnt matter.

i'd note that the arch maintainers did not consult with the package maintainers
before moving to stable.  none of the 2.2.4 versions should have been in stable
before -r3.

regardless ... if you have a problem and you want it properly tracked, file a
bug.  communication over irc is not trackable.

Well, he could have filed a bug couldn't he? That was required for release
material and since it went into the snapshot i had no hurry in fixing it.
So do we have the games herd commitment not to do this (direct to stable
against arch policy) again in the future and fix the current breakage (and
violation of arch policy) of app-emulation/vice (by restoring 1.20 and falling
back to ~arch keywords on 1.21)? If ppc and/or x86 want to keep it stable
that's their decision, i care about sparc in this case in particular.

you're free to set your arch to whatever you like in the vice ebuild

not even sure why games is the maintainer of vice anyways ... probably no one
else cares

No commitment no resolved then...

sorry, i didnt realize you need me to copy and paste comments for you

------- Comment  #27 From SpanKY  2007-05-02 21:14:00 0000  [reply] -------

let's review shall we ... i said the games team will start committing into
unstable ... what exactly else do you want done hmm ?

Ok, this bug has gone a lot longer than it needed, shall we take a deep breath,
call it good, and move on now?

Maybe the games team is kind enough to restore the latest stable that works
too...

...