from cvs log toolchain.eclass: ---------------------------- revision 1.653 date: 2015-02-10 08:22:00 +0100; author: jlec; state: Exp; lines: +2 -2; commitid: 2a0354d9b1984567; Revert unreviewed commit which breaks the tree ---------------------------- revision 1.650 date: 2015-02-09 21:05:07 +0100; author: vapier; state: Exp; lines: +2 -2; commitid: 375454d912f24567; use multislot for all cross-compilers and versions older than gcc-4.6 ---------------------------- revision 1.646 date: 2014-11-04 09:04:00 +0100; author: jlec; state: Exp; lines: +2 -2; commitid: 3bbe545888704567; Fix broken dependencies due to gcc multislotting, #528194, #528196 ---------------------------- revision 1.645 date: 2014-11-02 22:30:11 +0100; author: vapier; state: Exp; lines: +2 -2; commitid: 26195456a2624567; enable multislot for all versions <4.7 So it's already the second time vapier commits a similar change to toolchain.eclass, not caring to either do a proper list review or to check repoman output. I think we seriously need to take action to avoid such behavior in the future.
@mgorny, to see this bug, developers must be in both groups comrel and qa. CC Pinkbyte a qa team leader first.
Oh, sorry, I didn't notice the 'all'. It seems that I can't uncheck them now ;/. Want me to report a new bug or can you fix it? :)
(In reply to Michał Górny from comment #2) > Oh, sorry, I didn't notice the 'all'. It seems that I can't uncheck them now > ;/. Want me to report a new bug or can you fix it? :) I can, but pinkbyte asked me to add him to the list first.
Restriction lifted. @mgorny: in case you did not know, do not add aliases to CC list on restricted bugs - that would not work. Currently we can add all members of QA team to CC by explicitly adding them. If you wish that all of us should track progress of this bug - feel free to do so.
Why is comrel here? This is a technical problem. Dropping restriction to Gentoo Developers and removing comrel@
@hwoarang: with all my respect, how miscommunication and repeatevely commiting of reverted commits is a technical issue? Fall out of that actions is purely technical, yes. But not the cause of them.
(In reply to Sergey Popov from comment #6) > @hwoarang: with all my respect, how miscommunication and repeatevely > commiting of reverted commits is a technical issue? > > Fall out of that actions is purely technical, yes. But not the cause of them. We can't teach people how to talk to each other. You are QA. He is breaking the tree. So it's your domain. You have all the tools and power to take care of that. This is a "technical problem" since it has to do with tree breakage not personal conflicts.
when jlec reverted things, he never actually told anyone about the breakage (neither bug has anyone relevant cc-ed). the change was relanded later because i thought i forgot to update gcc ... i didn't realize jlec reverted w/out consultation. you might also want to refrain from making grandiose claims when you have no data. exactly *two* packages were broken, neither had stable keywords, and both are sci packages which tend to be uncommon.
You are in no position to close disciplinary action bugs against yourself.
you're attempting to show that i knowingly broke the tree multiple times while flouting the rules and ignoring other devs. the problem is you have absolutely no data to back up that claim, hence your bug is invalid. as i already explained, the only thing you've shown is jlec not communicating with the people he's reverting changes on. stop marking this bug private. if you want to discuss me, then do it in the open.
Adding comrel back, as vapier supplied evidence, that this issue is not only technical. @vapier Read again what mgorny wrote and comply with it this time. (In reply to Michał Górny from comment #9) > You are in no position to close disciplinary action bugs against yourself. @comrel Please take appropriate action. You are in charge to take disciplinary action [1]. [1] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct
again, stop closing the bug
I think we all need to take a deep breath here, and possibly a step back. I realize that looking at the commit output it might seem like Vapier is flaunting the rules but I really do not think that is the case here. It looks like, as vapier said, that jlec made a revert an didn't specifically tell vapier who recommitted the changes later thinking that he personally had forgot to commit. We have Vapier's attention now, let's just politely ask him to be more careful with these changes and move on with life. It does not look like his intent was to break the tree (even the old devs make mistakes) nor to purposely revert QA actions. Many of you know how rare it is for me to advocate peace, but I simply do not see any purposeful wrongdoing at this point. Let's get along and get his changes into the tree.
(In reply to Rick Farina (Zero_Chaos) from comment #13) thanks, that's exactly what's going on here i was a bit surprised there were any packages doing this as i've never run USE=-multislot on any system, and never had a package break because of it
@comrel: Do you intend to perform any action here? @qa: Are there any technical issues left that need to be resolved?
(In reply to Ulrich Müller from comment #15) > @qa: Are there any technical issues left that need to be resolved? I thought we said that use=multislot needs to go a long time ago since it is violating metadata rules. This topic has come up time and time again but we, as the qa team, have never followed through with it. [1] The bottom line is that SLOT is one of the top level variables that goes in the cache, so its value should not be changeable based on a use flag. So I think the qa team needs to make a decision wrt whether we are going to continue to allow this. [1] http://devmanual.gentoo.org/general-concepts/portage-cache/index.html
(In reply to William Hubbs from comment #16) These changes are related to the multislot USE flag, but jlec's reverts didn't remove it either. In fact, after Mike's latest change in r1.654 the multislot flag is disregarded for some toolchain versions: -if use multislot ; then +if ! tc_version_is_at_least 4.6 || is_crosscompile || use multislot ; then So one could argue that this even slightly improves the situation.
(In reply to William Hubbs from comment #16) USE=multislot isn't relevant here. the changes are independent of it.
* Mike committed unreviewed to an eclass breaking packages in the tree. * I used the most affective way to fix all packages by reverting the commit. That repeated. And now I get blamed for wrong behavior?
(In reply to Justin Lecher from comment #19) let me fix that list for you: * Maintainer committed a change to the eclass he maintains that broke packages * jlec@ reverted the change, but never actually told the maintainer so yes, by not actually talking to the person (both times actually) whose change you reverted, you were in the wrong
(In reply to SpanKY from comment #20) note: i'm not interested in blaming people here. that's a pointless exercise. the simple resolution is that, if you revert someone's change, you must notify them. this particular case would have been trivial -- cc toolchain@ on the bugs that were opened.
What I would do is to at least need to get the ACK from other team member to the changes in so "central" eclasses maintained by base-system and toolchain. That way we could prevent some of this problems as other eyes could detect some bugs/issues in the changes.
@Mike: Please don't mark bugs as resolved that are assigned to QA or ComRel, since you are not in any of these teams. @QA Team: I do not see any QA team action here. If you think that any commits have been inappropriate and merit sanctions, then, please get your act together and - write up what precisely was done wrong, with detailed reference to existing rules - state what type of sanction you have in mind - and confirm it with a majority vote of QA team members The general discussion about the multislot mechanism is not relevant here. I'm leaving comrel in CC for a few more days, but if we receive no information of a QA team vote we'll be off.
(In reply to Justin Lecher from comment #19) fwiw: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Communication_When_Making_Fixes
(In reply to SpanKY from comment #24) > (In reply to Justin Lecher from comment #19) > > fwiw: > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/ > Policies#Communication_When_Making_Fixes Before educating other, start learning how to commit without breaking other packages. And here I only mean the commits where problems accidentally happen, like in this specific topic. Your knowingly and forcible breakage of stable tree is a completely different topic.
(In reply to Justin Lecher from comment #25) Justin, please, take it down a notch. Nothing Mike did was to spite you, and even his behavior on this bug has been civil. You did the right thing reverting his breakage, you spared the users pain, and things appear to have been fixed properly now. That said, you should always tell the person who made the change when you have to revert something, especially when it's as major an action as reverting toolchain.eclass. No one is against you here, no one is trying to sanction anyone. Mike messed up and accidently broke the tree. You messed up by not telling him that you had to revert his commit. This was a miscommunication, it happens. I don't see any action needed by QA or comrel here. I vote close the bug.
QA team will take no action here (as discussed today in #gentoo-qa). Reassigning to toolchain.eclass maintainers.
