| Summary: | app-emulation/vice keyworded against policy | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gustavo Zacarias (RETIRED) <gustavoz> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo Games <games> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | anakin.skyw, caster, comrel, jakub.moc, jer, m.langer798, mr_bones_, ombudsman, qa, sgtphou, sparc, tristan |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | #gentoo-dev IRC log about the issue | ||
|
Description
Gustavo Zacarias (RETIRED)
2007-04-27 15:42:21 UTC
Created attachment 117414 [details]
#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... ... |