I've politely asked Samuli to update his workflow based on the Gentoo Council decision. I've politely reminded people on the -dev mailing list, even asked Petteri how the Council was enforcing this, the answer to all is that I should "file a devrel bug" - I'm sad it had to come to this, but I see no other resolution happening based on what I can say/ask/plead. -Jeremy One example of many commits: Revision 1.5 of http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/xfce-extra/xfce4-battery-plugin/xfce4-battery-plugin-1.0.0-r1.ebuild?view=log 15:46 <darkside_> hey man, are you really going to keep commiting without updating the CL even after the council decided? 15:46 <ssuominen> these EAPI4 bumps? 15:46 <darkside_> anything, yes. 15:46 <ssuominen> uh... was going to handle whole category, so yeah, these EAPI4 bumps for sure 15:47 <darkside_> why can't you just commit a CL entry too? 15:48 <ssuominen> I don't see it of any intrest to users if "EAPI=3 to EAPI=4" and cosmetic changes... 15:48 <ssuominen> just getting this done so I can commit the final cleanups to the eclass and migrate git-2 in 15:48 <darkside_> i guess that is why the community asked the council to decide. 15:49 <ssuominen> the intresting directory lacks ChangeLog altogether, eclass/ 15:49 <darkside_> and there was a decision 15:49 <darkside_> anyway, you agree that i have politely asked you to change your workflow, right? 15:50 <ssuominen> sure 15:51 <darkside_> ok, then i have been asked by multiple people to open a devrel bug 15:52 <ssuominen> ... 15:52 <ssuominen> you cant be serious 15:53 <darkside_> what can we do? we asked for a decision by the council and then i've asked for people to follow the decision 15:53 <darkside_> when you refuse after being asked politely... 15:53 <darkside_> idk, no other options, i guess 15:53 <ssuominen> I'll log everything worth logging for 15:53 <ssuominen> Why do you think it's important to log EAPI=3 to EAPI=4 ? 15:54 <ssuominen> Futhermore, why would that be of any intrest to users when the exact result of ebuild is same? 15:54 <darkside_> i've been burned so many times, trying to look in the CL for something that you have committed 15:54 <darkside_> it wastes my time 15:55 <ssuominen> Name a example or something, because I don't remember anyone altering my commits for a long time 15:55 <darkside_> when an ebuild version was removed is the perfect example 15:55 <ssuominen> it's the obvious answer on those, it's just old 15:56 <darkside_> carry on, it is clear that i can't change your mind after politely asking
While I understand the problem here, I kinda agree with Samuli. You see the changelogs from developer's perspective, so you need to be aware of each change that happens to an ebuild. OTOH, users do not care if an ebuild is EAPI4 or EAPI25. It makes no sense to them so the established policy in wrong by design. Logging everything leads to huge changelogs, increased portage size, etc etc. Anyway, since this is the established policy, we *must(?)* accept it. However, this decision was taken by Council alone, but I think QA could have offered some valuable insights on this thing. Could you please make this bug visible to QA group as well? Maybe council too? Personally, I am quite sad to see this kind of bugs. They only lead to demotivation and frustration and they slow things down without apparent reason. Also, if you force such things on developers, open source contribution stops being fun and pleasure as it was supposed to be.
(In reply to comment #1) > While I understand the problem here, I kinda agree with Samuli. You see the > changelogs from developer's perspective, so you need to be aware of each change > that happens to an ebuild. OTOH, users do not care if an ebuild is EAPI4 or > EAPI25. It makes no sense to them so the established policy in wrong by design. > Logging everything leads to huge changelogs, increased portage size, etc etc. I am a user. When my upgrade breaks, I do what "users" do, search ChangeLogs for relevant changes. Please don't say that I am not a user again, thanks. For the rest, I don't know about any process for these kinds of bugs, open it up as you see fit.
(In reply to comment #2) > (In reply to comment #1) > > While I understand the problem here, I kinda agree with Samuli. You see the > > changelogs from developer's perspective, so you need to be aware of each change > > that happens to an ebuild. OTOH, users do not care if an ebuild is EAPI4 or > > EAPI25. It makes no sense to them so the established policy in wrong by design. > > Logging everything leads to huge changelogs, increased portage size, etc etc. > > I am a user. When my upgrade breaks, I do what "users" do, search ChangeLogs > for relevant changes. Please don't say that I am not a user again, thanks. I am sorry if I expressed myself the wrong way. I didn't mean to offend you. However, I don't think that having a "Migrating to EAPI4" entry in the changelog would make any sense in this particular case. I am not sure about the process either so I'll stop here wait for the rest of the members.
Jeremy asked the council in #gentoo-council if the council would defend this policy or who should enforce it. Petteri suggested Jeremy should open a DevRel bug about it, so that's why this bug was "born". Markos, the point is that we now have an approved policy and one that on purpose doesn't allow "exceptions", so everyone should be following it. One might forget to add a ChangeLog, but that's not the case here. Samuli has expressed and continues to express no interest in adding ChangeLogs, even after the policy was approved. As I said in #gentoo-council, as Samuli is a QA member I feel the QA team has an extra responsibility here and should be addressing this (I have no inside knowledge to know whether that's the case or not). In any case, as this bug was filled, the Developer Relations team shall process this bug whether QA addresses this issue or not. A DevRel member shall take this bug and process it asap. PS - My comment here was made both as a council and DevRel member, but at this time I'm not processing this bug for DevRel.
I'm adding Samuli to the bug so he can follow the bug and add any information he finds relevant. I'm also adding Diego as the QA lead per my last comment.
Sigh. I'm seriously disappointed. Samuli was I not clear enough in my mail from April 30th? I'm sorry but this has gotten old. This is no longer a request: use echangelog before committing. Full stop. And if you keep insisting not using them, you'll get kicked out of QA and put on suspension.
Why not having 'repoman commit' automatically append the commit message to Changelog, declare peace, optionally make love, and be done with the situation threats and all? Denis.
Last time it was a bloodbath of bikeshedding. I agree it would be a good idea, but given the insistence Samuli and Mike have on not using ChangeLogs, I'm more afraid of a comeback in not using repoman to commit at all..
I'm getting the impression the most easiest target is getting picked here as an example, or scapegoat. Doesn't really seem fair, take a minute to think about it. The same styled selective ChangeLog applying has been used, is used, and will be used by several other developers as well. The said group of developers constitute large amount of total gentoo-x86 commits[1]. Finger pointing is not nice, so I'll skip naming them. I have to ask. Are you really doing a favour to the project with any of this? This certainly has nothing to do with QA, and I'm sorry to say this, seems more like ego boosting and spiteful behavior. [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/ I will continue logging everything worth logging and I'm sure others in question will as well. This has worked fine for years, nothing has changed in that regard. Some trust on the judgement of other developers would be nice, I know I have it for others. And I wasn't trying to be condescending nor was this targeted to anyone in particular. Also would like to request on making this bug public, got nothing to hide here.
(In reply to comment #9) > I'm getting the impression the most easiest target is getting picked here as an > example, or scapegoat. Doesn't really seem fair, take a minute to think about > it. > As Devrel lead: Note that this bug was initially filed by an individual. If it was filed by QA when they knew there where others breaking policy them I would agree here. DevRel does not monitor the tree so we do not actively open these kinds of bugs but if they are filed we plan to handle them all equally. > [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/ > > I will continue logging everything worth logging and I'm sure others in > question will as well. This has worked fine for years, nothing has changed in > that regard. Some trust on the judgement of other developers would be nice, I > know I have it for others. > As Council member: One motivation behind the council decision was that based on the meeting logs and preceding email discussions we can not trust the judgement of all committers on the top of that list. Arfrever tried his best to have holes which would allow him to continue as much of the old behavior as possible. ChangeLog files are not useful if you can't rely on them. Even with a smiley this kind of comment tells much about the general intention: 19:52 < Arfrever> The patch for devmanual doesn't disallow `ln -fs /bin/true /usr/bin/echangelog` :) . > > Also would like to request on making this bug public, got nothing to hide here. Devrel: Jeremy: Is this ok? As Jorge has expressed that he will take this bug I will refrain from further commenting to give him the space to do his job. Also please remember that this bug is not about the content of the policy itself but about knowingly refusing the follow a policy. We are just too big to have no rules and when we do they should be the same for everyone.
(In reply to comment #10) > > Also would like to request on making this bug public, got nothing to hide here. > > Devrel: > Jeremy: Is this ok? As long as the reporter and the target of the bug are ok with opening a bug, there's nothing preventing it from being open. > As Jorge has expressed that he will take this bug I will refrain from further > commenting to give him the space to do his job. Also please remember that this > bug is not about the content of the policy itself but about knowingly refusing > the follow a policy. We are just too big to have no rules and when we do they > should be the same for everyone. (In reply to comment #4) > PS - My comment here was made both as a council and DevRel member, but at this > time I'm not processing this bug for DevRel. Petteri, I think you misread my above comment ;-) If no other DevRel member wishes to intervene here, I'm open to process the bug, but given my current workload, I'd prefer if another member could take this bug - to avoid dragging this for lack of free time.
Let it be clear on record: my personal preference for ChangeLogs (that is to update them) has nothing to do with why I'm telling you to do that. The point is that there is a policy and you should follow it, and if you feel it's wrong, discuss it while following it. You don't just ignore a rule because you don't like it and pretend it's all fine, gotcha?
1) You aren't a "scapegoat" 2) I've already told devrel to open the bug as they see fit, I'm fine with it being open. 3) Since I have already asked other developers to use the ChangeLog on ebuild removal, there will be more bugs like this. (Including one recent instance where the Manifest was broken for a few minutes.)
@Infra please disable Samuli's commit privileges. Samuli, you've officially pissed me off.
(In reply to comment #14) > @Infra please disable Samuli's commit privileges. > > Samuli, you've officially pissed me off. none of this is a QA issue, no idea what you are even doing here. learn to behave.
(In reply to comment #8) > Last time it was a bloodbath of bikeshedding. I agree it would be a good idea, > but given the insistence Samuli and Mike have on not using ChangeLogs, I'm more > afraid of a comeback in not using repoman to commit at all.. Understood. Now (and I'm sure this question has been asked and answered before), is it technically possible to prevent commits from not going through repoman? I know in some situations you can't use repoman and need to use 'cvs commit' but in this case let's fix repoman. (In reply to comment #14) > @Infra please disable Samuli's commit privileges. > > Samuli, you've officially pissed me off. Let's hope it's not the reason for his commit privileges to be suspended because I don't see that in any policy. In other words: let's cool down. And following a mid-air collision: (In reply to comment #15) > (In reply to comment #14) > > @Infra please disable Samuli's commit privileges. > > > > Samuli, you've officially pissed me off. > > none of this is a QA issue, no idea what you are even doing here. learn to > behave. Not exactly the best way to ask anybody to behave. Again: let's cool down. Denis.
(In reply to comment #16) > (In reply to comment #8) > > Last time it was a bloodbath of bikeshedding. I agree it would be a good idea, > > but given the insistence Samuli and Mike have on not using ChangeLogs, I'm more > > afraid of a comeback in not using repoman to commit at all.. > > Understood. Now (and I'm sure this question has been asked and answered > before), is it technically possible to prevent commits from not going through > repoman? I know in some situations you can't use repoman and need to use 'cvs > commit' but in this case let's fix repoman. Everyone mentions "fixing" repoman like its the golden bullet to fixing this. There are less than 5 people that do not update ChangeLogs on a regular basis (I know, I've been following this for a long time now). This is a simple policy that needs to be followed, and it really isn't that difficult since we have 100s of others doing so on a daily basis. > (In reply to comment #14) > > @Infra please disable Samuli's commit privileges. > > > > Samuli, you've officially pissed me off. > > Let's hope it's not the reason for his commit privileges to be suspended > because I don't see that in any policy. In other words: let's cool down. So, what is supposed to happen to someone that doesn't follow documented policies? Allow them to continue ignoring policies as they please until devrel finally makes a decision? Seems pretty silly to me.
(In reply to comment #17) > Everyone mentions "fixing" repoman like its the golden bullet to fixing this. > There are less than 5 people that do not update ChangeLogs on a regular basis > (I know, I've been following this for a long time now). This is a simple > policy that needs to be followed, and it really isn't that difficult since we > have 100s of others doing so on a daily basis. Agreed. However, repoman is a good tool but it could be made better by automatically committing a changelog entry identical to the commit message. There's the fact that it would be easier to enforce some policies (such as committing a changelog entry being mandatory) but it would also save time to everybody making it easier to follow policy. The latter is mostly unrelated to the former. If it's not doable then it's not doable. I was just asking a question above, not threatening you with a gun (to go on with your bullet analogy). > So, what is supposed to happen to someone that doesn't follow documented > policies? Allow them to continue ignoring policies as they please until devrel > finally makes a decision? Seems pretty silly to me. That was not my point and you know it. OK now. If there is a trigger-happy majority who want to retire Samuli or anybody else, then please proceed. Because let's be honest that's where this is going based on past experiences. I am not opposed to the idea at all, I mean it, and my history at devrel proves it. When are we tackling vapier's case? Are your balls not big enough? You should however first make sure that it makes sense and that you don't mind living with the idea of being on someone else's radar. Because that happens eventually, believe me. For what I know some of you might already have a bull's eye in their back. Is "Gunfight at the OK corral" your idea for gentoo's future? There has to be an alternative to that. Denis.
Retiring in NOT an option. From my perspective, Samuli is doing a great job. He practically maintains 1/5 of the tree on his own. So think twice before you kill his motivation like that. I agree that established policies should be followed, but are you ready to hurt Gentoo and slow down its progress in so many areas? You cannot put all the policies under the same umbrella, neither you can claim that all of them have the same severity to our project. Finally, I would like to see similar bugs for Mike, me, Arfrever and whoever is committing anything without writing to Changelogs. If you want to enforce policy compliance, please do the same for all developers.
(In reply to comment #19) > Retiring in NOT an option. But it has unfortunately been the usual outcome of a temporary suspension over the past few years. One notable and recent exception to that is Arfrever who sticks more than a fresh bogey. The ones you'd like to stay after a suspension typically don't. Denis.
Of course they don't since they don't have the motivation anymore. As I said, on my very first comment, opensource contribution is supposed to be fun. Everybody here sacrifices his free time time to give something back to the community. Our policies should be flexible and point to the right direction. Forcing someone to retire because he does not follow a policy, but OTOT he improved your project by a factor of X, is naive. The simplest solution would have been to patch repoman to create an entry, if the developer did NOT touch the changelog before invoking repoman commit. Simple solution and everyone is happy (until next time)
Is it really happening? You're seriously consider suspending/retiring Samuli over not updated Changelogs?
(In reply to comment #22) > Is it really happening? You're seriously consider suspending/retiring Samuli > over not updated Changelogs? The other side (and this includes me) is saying "Is it really happening? Are you seriously refusing to update ChangeLogs despite being asked by several people including the Council to do so?" Just so I understand, Samuli, Markos, others - is your refusal only based on the amount of time the additional committing takes?
The refusal is based on common sense. Fixes that do not affect end users like "fixing copie to copy typo" or "Use EAPI4" make no sense so why should it be logged. Nothing can go wrong, nobody can tell something changed ( behavior wise ) so why should I add +3 more bytes ( imagine I do that 1000 times -> 3000 bytes additional size on portage tree for *nothing* ) and wait +3'' for echangelog. However, the policy as stated in devmanual states that everything ( even the more stupid typo ) should be logged. There is clearly something wrong in the process and forcing such policy just because nobody came up with a suitable technical solution is just sad.
(In reply to comment #22) > Is it really happening? You're seriously consider suspending/retiring Samuli > over not updated Changelogs? Kacper and others, the council approved a policy. Developers are free to disagree with said policy, but everyone is *required* to follow it, even if / while trying to change it or revert it. Do we (me, Diego, Jeremy, QA, council, whoever someone feels like blaming) really want to force Samuli, Mike or anyone else not following this policy to retire? Obviously not! But we also can't let every developer decide that policies don't apply to him/her and act as if he/she isn't part of a team and doesn't have to follow rules. I agree and want work on Gentoo to be fun, but that doesn't mean we don't have to follow some rules. Furthermore, let's put this into context, this policy tells developers to always use ChangeLog when commiting, so all we're asking is that you move from something like: <work on ebuilds> <test ebuilds> repoman manifest repoman full repoman commit to <work on ebuilds> <test ebuilds> echangelog repoman manifest repoman full repoman commit There are a few examples floating around and our developers are more than capable to update their commit scripts to add a call to echangelog using the same message they're going to use on repoman commit. So anyone "actively" refusing to follow this policy is after a conflict or is trying to "test" the enforcement bodies in Gentoo. Finally, Diego as the QA team lead used the power granted in GLEP48 [1], with the revisions made by the current council, to have a developer commit privileges suspended. By my part, as a council member, I'm happy to see the QA team is addressing an issue where members of the team, "actively" disregard established policies. [1] - http://www.gentoo.org/proj/en/glep/glep-0048.html Samuli, please start using echangelog. It's not that "hard" nor is it a "crazy" idea. I've addressed Samuli directly as this bug was filled about his behaviour, but I also address the above request to everyone currently not using echangelog.
(In reply to comment #24) > The refusal is based on common sense. Fixes that do not affect end users like > "fixing copie to copy typo" or "Use EAPI4" make no sense so why should it be > logged. Nothing can go wrong, nobody can tell something changed ( behavior wise > ) so why should I add +3 more bytes ( imagine I do that 1000 times -> 3000 > bytes additional size on portage tree for *nothing* ) and wait +3'' for > echangelog. However, the policy as stated in devmanual states that everything ( > even the more stupid typo ) should be logged. There is clearly something wrong > in the process and forcing such policy just because nobody came up with a > suitable technical solution is just sad. Markos, unfortunately the council had to approve this policy has developers kept looking for loopholes in the policy to refuse to use echangelog. I was sad to see we have to approve such policies because people refuse to follow "common sense", but that is the current reality in Gentoo.
(In reply to comment #25) > By my part, as a council member, I'm happy to see the QA > team is addressing an issue where members of the team, "actively" disregard > established policies. Not all QA members are aware of this bug so I am adding qa@ to the alias. As for your last comment ( comment #26 ) I completely understand what you are saying and your current point of view. But, please be fair and open similar bugs for the rest of us. I don't like putting all the blame on a single developer.
> As for your last comment ( comment #26 ) I completely understand what you are > saying and your current point of view. But, please be fair and open similar > bugs for the rest of us. I don't like putting all the blame on a single > developer. Samuli was warned before not to commit without changelogs, same apply for the other devs, if they continue to disregard the policy they will get their own shiny bugs.
I don't agree with the way Samuli handles ChangeLogs. I would really like it if he started running echangelog before repoman commit. However, a bug like this is probably the *worst* possible way to have a dialog with someone on /any/ issue. This bug has turned into a trial. Samuli is the defendant and everyone else is the plaintiff. This kind of thing does not fit inside our model of voluntary FOSS contribution. We all need to take a step back and ask ourselves: what is the purpose of this bug? Is it to convince a developer to follow a policy or to punish him for not doing so? The way I see it, this bug serves the latter purpose. "Follow policy or get punished" is a really stupid stance to take with volunteers if your aim is to keep them around. The solution? Listen to each other, understand each other. Rinse, repeat till you come to a conclusion. None of the people taking part in the discussions on this bug are malicious, I'm sure everyone can come to an understanding. Take your time, this problem of ChangeLogs is **not** time-critical. The harm done by missing ChangeLog entries is negligible when compared to the time wasted and energy + motivation lost (on both sides!) by the heated conversations here. Please talk to each other and listen to each other. Remember, we're doing this for Gentoo, not for ourselves.
Thanks for the QA CC. I did not know about this bug... A number of points to make. I'll try to keep it brief, however, I will likely fail. First, as a member of QA, I find it honestly sad that things have degraded to this. I fully understand both points of view. Both make sense in their own right. But reacting to it like this does *not* help the issue. It reflects poorly on QA, and on Gentoo as a whole. There are appropriate ways to handle things. This is *not* it. > > Markos, > > unfortunately the council had to approve this policy has developers kept > looking for loopholes in the policy to refuse to use echangelog. I was sad to > see we have to approve such policies because people refuse to follow "common > sense", but that is the current reality in Gentoo. While I understand the analysis of the current state of Gentoo so to speak, the way it was handled was perhaps not the best. I'm sorry I had to miss the council meeting this occurred in. The simple fact is that if there are developers who can't use common sense(and I agree that there are some, but not many), they need to be dealt with. We can't (and shouldn't) have policy for everything just to reign in a handful of people. The simple fact to all of this is that I really hate to see a triviality such as this causing this amount of, well, for lack of a better word, crap. It's a bloody ChangeLog. QA/DevRel is in the position of trying to enforce this, and it's going to be painful to try to do so (as if enforcing already existent policies isn't painful enough). Already we are seeing that. We have commit rights being asked to be suspended, talk of retirement, etc etc over updating a CHANGELOG. It's bad enough when there is talk of such stuff when someone blatantly disregards policy, and due to that breaks the tree. Not using the changelog will NOT break the tree (but doing something and breaking the tree and not having it in the ChangeLog can be a headache). But in the same breath, it is still policy, and is it really that ruddy hard? Script it for crying out loud: #!/bin/bash echangelog "${1}" repoman commit -m "${1}" Done. Dealt with. If you want the policy changed / reworded, by all means, bring it back to the mailing list. Bring it back up at a council meeting. But do *not* put QA/DevRel in the position of having to make these requests over something so ruddy stupid and trivial. As to my technical opinions on the topic of ChangeLogs, I'll save it for the ML's. I've spammed this bug enough. Just my 2 cents. (In reply to comment #29) > Please talk to each other and listen to each other. Remember, we're doing this > for Gentoo, not for ourselves. Could not agree more.
(In reply to comment #22) > Is it really happening? You're seriously consider suspending/retiring Samuli > over not updated Changelogs? Invert that. Is Samuli really generating this amount of idiocy over updating a fucking changelog for the benefit of other people? I'd be less annoyed if this was skirting the rules; instead it's flat out "yeah, I'm not doing it". As Dane said... this isn't really much of a conversation and is a bit annoying it's gotten this far. Samuli knows the requirements for having access to gentoo-x86 cvs. If he wishes to have access, he needs to follow them (meaning do the !@#*ing changelog and stop being stubborn). I'd rather he keep contributing, but he needs to do changelogs, period. If he refuses, well the end results are known.
Okay I want to be crystal clear. I am not going to care about anybody's feeling here. Why? Because that offer passed when, asking Samuli and Mike to follow procedures, I was ignored for the best part of the month. Yes, this is a QA issue, as missing change log entries make it very difficult for even users to track down why a package failed to build now, while it worked, say, yesterday. Sure, if you think that there is no way to make a mistake, Changelogs aren't interesting. But we're all humans and mistakes need to be taken into proper consideration. Plus, council decided, you should follow their lead. At worst you can appeal, but ignoring both the council, the complainers and the lead (and co-lead) of QA that you also elected, is not the way to proceed. And insisting on doing so well after I asked you multiple times to follow the policy, is definitely the kind of behaviour that doesn't play nice to me. I didn't expect that the bug would be made public, not at least until similar bugs were opened against the remaining offenders, but since you got - once again I'm afraid I have to say - Denis insisting on the pure feeling side, the offenders (bad name unfortunately) defending the protest, and a number of people covering the technical/policies side. I think this means that either you make it a popularity contest or you apply policy. I'm going for the latter. Especially since Samuli did not even reply to my first complain with any technical reason for not complying. I'm sorry but like I was of strong opinions on the python incidents I'm of strong opinions now.
Let's make something clear here: - I log everything intresting to users in ChangeLogs. - I use often cvslog messages of 'punt old, fails to build with libfoo' which are way more informative than cvslog+echangelog of 'Remove old.' which tells absolutely nothing why the files got removed. - The mail Diego sent earlier last mont was plain insult with extremely rude tone, you he got lucky I didn't open devrel bug on about it then. I saw it best to ignore such ramblings. - The yesterdays Xfce commits were _all_ compile tested AND I reviewed _every single_ commit I made from gentoo-commits ML. So yes, humans do make mistakes and I've ensured there was none. - Futhermore I do review ALL my other commits too after committing from ML. - I have no plans whatsoever changing the current workflow. Nobody has pointed a SINGLE point of failure on it. Futhermore it's funny how the most loud people here are the ones with least commits. I suggest you start being productive, and leave others do their work in peace. I really hope you don't bother other developers with this kind of useless attacks, because not everyone is forgiving as I am.
Futhermore I don't see a reason to defend myself here futher since there is nothing to defend about as nobody has pointed a single technical fault on the current workflow. Certainly has absolutely nothing to do with QA.
I strongly suggest you revert the poorly thought out policy change that was committed on devmanual, stop enforcing this just "because you can" on people doing proper work and leave it for the next council to figure out which shouldn't be too far now.
How do you get to decide what is proper, Samuli? It is obvious that there is strong disagreement in the two camps so it was escalated to the Council as the entity to decide. They decided and now we should follow it. One could argue that if no one follows policy that the Council sets forth that the Council is worthless and shouldn't exist.
(In reply to comment #36) > How do you get to decide what is proper, Samuli? It is obvious that there is > strong disagreement in the two camps so it was escalated to the Council as the > entity to decide. They decided and now we should follow it. One could argue What should be focused on is the _context_ of the log messages, not the _location_ of the log. That's where we have room for improvement as people tend to be lazy to write about it and we have the previously described scenario where you have to find the committer and ask him about it -- that shouldn't be required in the first place. I certainly don't remember receiving such questions. But still, old is just old and that's that. > that if no one follows policy that the Council sets forth that the Council is > worthless and shouldn't exist. I never said that. Please, don't try to escalate this...
(In reply to comment #37) > I never said that. Please, don't try to escalate this... I'm not. Your actions already have escalated this. (See bug title: "refusal to follow policy" - emphasis *refusal*) I deal with this type of situation in real life. The situation is, a group of people cross the line and break policy on a minor thing. The next generation of the group learns from the elders about this and think that it is ok to cross that line because they don't know any better. They, themselves, then cross the next line on a more serious issue and the cycle continues until something bad happens and then there is over regulation. Luckily, what we discuss here in this bug report is not life threatening like my real life situation and we can much more easily solve this. I've very reasonably asked for a change in your workflow (even though you don't agree with it) until you lobby for a change in policy yourself, similar to what the group did to get this policy put in place.
(In reply to comment #38) > (In reply to comment #37) > > I never said that. Please, don't try to escalate this... > > I'm not. Your actions already have escalated this. (See bug title: "refusal to > follow policy" - emphasis *refusal*) It's matter of level you want to enforce a policy. Could be understandable if this was put upon someone who broke something and left no logs about it. Assuming people aren't spineless and try this on our main toolchain/base-system maintainer, as well as games maintainer as well -- do you honestly think it's benefical to the project to risk losing these people over this?
(In reply to comment #39) > It's matter of level you want to enforce a policy. The term for that is "flexibility" -- no foss project can work without it.
I will handle this on behalf of developer relations as no-one else has taken this so far (sorry Jorge about misreading your comment). It seems we are playing a game of chicken here. On one side it is beneficial for the community as a whole to be able to rely on ChangeLogs and it's not in our interest to loose any developers over the issue. Developer Relations can't change council voted policies and QA has also expressed their desire to uphold the current voted policy so I don't think it's possible for DevRel to mediate and try to find a compromise. DevRel is also not a body that should give an opinion on the technical merits of policies. As such I think this issue falls under the following category found in our policy guide: "Complaints that do not require mediation per se are dealt with exclusively by a vote of the Developer Relations team. Problems for which mediation has been unsuccessful are also escalated to a vote of the Developer Relations team." http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap2_sect3 This means I will immediately start the voting process. Please note the following: "Each party is given three days to present information on the issue, at the end of the third day the team will review the information regarding the issue and vote on a resolution." I consider QA also a party in this dispute so I would like you to submit your opinion on the issue during this time frame. Please note that the issue we will be voting on is not the policy itself but the refusal to follow rules set by the project.
As Petteri is taking this bug for Developer Relations, the following comment is made solely as a council member. (In reply to comment #34) > Futhermore I don't see a reason to defend myself here futher since there is > nothing to defend about as nobody has pointed a single technical fault on the > current workflow. Certainly has absolutely nothing to do with QA. This is all about QA as one of the roles of QA is to enforce established policies in the tree. Like it or not, the council approved a policy. (In reply to comment #35) > I strongly suggest you revert the poorly thought out policy change that was > committed on devmanual, stop enforcing this just "because you can" on people > doing proper work and leave it for the next council to figure out which > shouldn't be too far now. I'm sorry Samuli, but as a council member I have to say that if you want to "ask" for a policy change, no you don't get to "strongly suggest" it, you have to follow the rules and get support for it in the dev ml, where you should have participated in the discussion prior to its approval. That doesn't excuse you from having to comply with the policy, though. Furthermore, this council hasn't reached the end of its term yet and has complete "legitimacy". You and all other developers will soon have a chance to elect a new council and you will be able to judge the work of any of the current members if they choose to run again for election. But until then, this council can and will enforce, if it so chooses, its policies.
<hat type="infra"> As per requests to infra in this bug, and direct request from jmbsvicetto in #gentoo-infra: I have now removed ssuominen's commit privileges to any repos cvs.g.o (flycatcher). Overlays access remains unaffected. </hat> <hat type="personal"> Can somebody just wire echangelog into repoman and stop bothering about the entire thing? Council/QA passed the changelog requirement, ergo any perceptions of messy changelogs are their problem, and not worth the entire argument of this bug, that's taking development time away. </hat>
(In reply to comment #43) > <hat type="infra"> > As per requests to infra in this bug, and direct request from jmbsvicetto in > #gentoo-infra: I have now removed ssuominen's commit privileges to any repos > cvs.g.o (flycatcher). Overlays access remains unaffected. > </hat> > The current wording GLEP 48 (I don't know why it's yet not committed) requires the following: "In case a particular developer is an immediate danger or persistently causes breakage to the tree, either the QA lead or two members of the QA team may request commit rights of given developer to be suspended by anyone with such privileges (currently Infra and Devrel team)." http://dev.gentoo.org/~scarabeus/glep-0048.diff Diego can you for the record state why you think leaving out ChangeLog entries is an immediate danger or causes breakages?
It causes breakage on the recording of information that the ChangeLogs are there for. Tree consistency does not only mean breakage for the users. I'm sorry but just defying the policy because you disagree with it is definitely not a good choice; as Jorge said, if you don't like working following said policy you can either change it or not work, but engaging in active defying of it is not a good choice. By the way, if it wasn't clear enough for the "repoman should update ChangeLog" camp, I filed bug #337853 last September. The fact that it has lead to nothing should tell enough I guess.
(In reply to comment #45) > It causes breakage on the recording of information that the ChangeLogs are > there for. Tree consistency does not only mean breakage for the users. > > I'm sorry but just defying the policy because you disagree with it is > definitely not a good choice; as Jorge said, if you don't like working > following said policy you can either change it or not work, but engaging in > active defying of it is not a good choice. Defying is often the first step in getting policies changed; eg. civil disobedience. > > By the way, if it wasn't clear enough for the "repoman should update ChangeLog" > camp, I filed bug #337853 last September. The fact that it has lead to nothing > should tell enough I guess. It tells us that no one implemented it yet. I suggest someone from the 'we require changelogs' group submit some patches to repoman. It is also obvious that the policy is fairly controversial...expecting everyone to just suddenly adapt is quite a naive view (IMHO). This is not an organization of a few dozen people. Change takes time, it takes tools, it takes training. At some point this place was a meritocracy. If a measure of a developer's merit is the number of commits, firing your highest merit developers over a minor policy violation is also likely 'not a good choice' as you so eloquently stated above.
We know Samuli isn't the only one in this situation. Thus, and in order to avoid having to vote on each of them on a case-by-case basis and running the risk of reaching a different decision which would not make any sense at all, here is what I would like us (devrel) to do: 1- make a list (or at least a tentative list) of all the developers with the above behavior 2- vote once and for all of them 3- if others show the same behavior while we're making the decision or after then apply the same decision I'm afraid I'll vote against any individual suspension until we do this. Because the problem isn't about who but about what. Denis.
The following expresses my views as a Gentoo developer, a DevRel member and also as a council member. (In reply to comment #47) > We know Samuli isn't the only one in this situation. Thus, and in order to > avoid having to vote on each of them on a case-by-case basis and running the > risk of reaching a different decision which would not make any sense at all, > here is what I would like us (devrel) to do: > > 1- make a list (or at least a tentative list) of all the developers with the > above behavior > > 2- vote once and for all of them > > 3- if others show the same behavior while we're making the decision or after > then apply the same decision > > I'm afraid I'll vote against any individual suspension until we do this. > Because the problem isn't about who but about what. > > Denis. In my view DevRel bugs should be judged on a per-case basis. The goal of the DevRel team while working on bugs is to try to find the best solution for the distro taking into account the individuals at stake. In some cases the team will mediate a conflict between parties and on others will have to evaluate the general behaviour and history of individual developers and see if they conform to the accepted behaviour and well being of this distribution. I understand your point here and I agree with it, but thinking about this whole issue, my opinion is that the request made by Jeremy in this bug should fall to the QA team and not DevRel. The request is that "someone" addresses the "refusal to follow policy on ChangeLog generation". As this is an established council policy and that the Gentoo body assigned with the responsibility to check and enforce the distribution policies is QA, I think this issue should fall to the QA team. However, my opinion here isn't the current approved policy on GLEP48 as it requires that any temporary solution imposed by QA be justified in 14 days and a case presented to DevRel[1][2][3]. Given this bug was assigned to DevRel, Petteri accepted this bug for DevRel and started the process requesting a vote, the ball is on our side. Having a consistent decision for every developer not following a policy is desirable, but how do we balance that with the evaluation of a developer behaviour and history? Do we want DevRel decisions to take into account solely rules or should it keep taking into account the "human" factor? While we expect for the parties to present any evidence for the requested voting, as a DevRel member I'll be thinking about the above. I'm adding council to the CC list because of the status of GLEP48. We need the approved changes in the council meeting to be committed to the GLEP. Tomas, please take care of the update. Diego and Petteri, we (QA and DevRel) also need to take care of the last re-wording about how the teams would cooperate. [1] - http://www.gentoo.org/proj/en/glep/glep-0048.html [2] - http://www.gentoo.org/proj/en/council/meeting-logs/20110308.txt [3] - http://dev.gentoo.org/~scarabeus/glep-0048.diff As my opinion about the relation between DevRel and QA has shifted a bit since I voted as a council member the last change to GLEP48, I'll follow the rules and submit a proposal for some changes to the GLEP through the mls.
(In reply to comment #48) > Having a consistent decision for every developer not following a policy is > desirable, but how do we balance that with the evaluation of a developer > behaviour and history? You need to step back right there and think carefully about what you wrote. If your idea of devrel is being unfair and judging devs differently for the same (supposed) mistakes, then you need a long vacation far away from Gentoo. I'm very serious Jorge, it really looks like you (and others) have completely lost it. Like you're in a dead-end unable to back-up because you won't admit you took a wrong turn somewhere. Denis.
(In reply to comment #47) > 1- make a list (or at least a tentative list) of all the developers with the > above behavior > > 2- vote once and for all of them This is impossible since other developers may react differently on similar bug. As I read this bug the only problem with have is
(In reply to comment #47) > 1- make a list (or at least a tentative list) of all the developers with the > above behavior > 2- vote once and for all of them > 3- if others show the same behavior while we're making the decision or after then apply the same decision Denis, this is impossible since other developers may react differently on similar bug. The problem devrel have here is Samuli's refusal to follow policy and insisting in doing this. But still I'm thinking about something that is in line with your suggestion, that is, as I read it, an attempt to define our actions (rules of game) in similar cases of policy violation. IOW I'd like to define the process (where QA team is involved) to report and handle QA policy violations. One possible process is: 1. Notify developer about violation by mail CC'ing QA team. Since any developer can spot such issue, QA team should support or decline this request, making replay to all with resolution. 2. After violation was supported developer must fix it, by doing new commit that address issue or by reverting commit that caused this violation. This should be done before any other commit. 3. In case the next developer's commit was different commit access should be suspended until devrel resolves this issue. I think that such formalization has lots of advantages: the tree will be clean from QA bugs as developer will have to fix issue; developer will learn on his/her mistakes; clear rules of game should make lengthy discussions like this bug futile since our actions will became unavoidable. Of course I'm late with this suggestion for this bug, but if we agree on this it should simplify our future life. I'll send message for discussion into -dev tomorrow.
(In reply to comment #51) > similar cases of policy violation. IOW I'd like to define the process (where QA > team is involved) to report and handle QA policy violations. One possible > process is: Please all the talk about processes etc. should not happen on this bug. This will be comment #52 and for handling the issue all devrel members need to be reading all the material so let's use this bug only for comments directly related to Samuli's case and all general discussion should happen on mailing lists.
Based on policy as described in comment #41, today is the last day of the given deadline for both parties to present the necessary information regarding this case. So where are we if I may ask?
(In reply to comment #53) > Based on policy as described in comment #41, today is the last day of the given > deadline for both parties to present the necessary information regarding this > case. So where are we if I may ask? Giving information is not mandatory so if no-one presents anything we will just have to evaluate the situation based on the available information. Given that Samuli has his commit access suspended until we have voted on the matter we should not make him wait for input from other parties at least.
(In reply to comment #54) > (In reply to comment #53) > > Based on policy as described in comment #41, today is the last day of the given > > deadline for both parties to present the necessary information regarding this > > case. So where are we if I may ask? > > Giving information is not mandatory so if no-one presents anything we will just > have to evaluate the situation based on the available information. Given that > Samuli has his commit access suspended until we have voted on the matter we > should not make him wait for input from other parties at least. Thanks Petteri for the reply. I completely agree with you. We should deal with this one as soon as possible. Lets not drag it more than necessary
Created attachment 274499 [details] Statement from QA team So I am finaly replying to this bug and adding QA statement for the issue. @Markos, Samuli: Guys we are QA, this mean that we can't just jump around and ignore policies. If we don't agree with some we focus on altering it, but we should never violate them as we are the ones that are supposed to overview others. (Would you listen to guy that tells you that speeding in a car is bad thing when you see him doing it every day?) @general: It will be great loss if Samuli decide not to work as Gentoo developer anymore, but the statement says exactly what we expect him to do.
(In reply to comment #54) > Giving information is not mandatory so if no-one presents anything we will just > have to evaluate the situation based on the available information. Given that > Samuli has his commit access suspended until we have voted on the matter we > should not make him wait for input from other parties at least. It's been more than a week since Samuli got his access suspended. 3-days deadline for presenting information is also overdue... Devrel could you have the courtesy to proceed? Especially due to the fact that Samuli still cares about g-x86 by requesting version bumps, submitting patches, b.g.o, etc.
(In reply to comment #56) > Created attachment 274499 [details] > Statement from QA team > bs, never saw such statement go in vote at QA and never nothing being agreed by majority at QA's end. futhermore I see you removed yourself from the QA team yesterday? nice hit and run. disappointing. now that there has been no proof of anything being broken in the first place, could the access be just restored so i can keep working?
(In reply to comment #56) > Created attachment 274499 [details] > Statement from QA team > > So I am finaly replying to this bug and adding QA statement for the issue. > > @Markos, Samuli: > Guys we are QA, this mean that we can't just jump around and ignore policies. > If we don't agree with some we focus on altering it, but we should never > violate > them as we are the ones that are supposed to overview others. > (Would you listen to guy that tells you that speeding in a car is bad thing > when you see him doing it every day?) > > @general: > It will be great loss if Samuli decide not to work as Gentoo developer anymore, > but the statement says exactly what we expect him to do. You can't really call the attached document QA statement. Maybe Tomas' statement but definitely not QA *team* statement. Never discuss about this neither on alias not or ML. You can't decide on your own and then call it "team" decision
(council hat on) (In reply to comment #58) > (In reply to comment #56) > > Created attachment 274499 [details] > > Statement from QA team > > > > bs, never saw such statement go in vote at QA and never nothing being agreed by > majority at QA's end. futhermore I see you removed yourself from the QA team > yesterday? nice hit and run. disappointing. Given all the comments here from QA members, I find this worrying. I get the impression the only QA members that care about the team doing what it should (enforcing policies in the tree) are either being pushed out of the team or just losing their motivation to be part of the team. > now that there has been no proof of anything being broken in the first place, > could the access be just restored so i can keep working? There is plenty "proof" of something being broken (the echangelog policy) and you keep making the point to "defy" and "refuse" following said policy. @council: seems we might have to look at QA team role, GLEP48 and check what we can do to ensure we get a working team.
That is the joint statement of the QA lead and deputy lead, not Tomas personal statement. That _is_ the official statement, let it be clear. Those who disagrees are actually invited to leave QA, for what I'm concerned.
(In reply to comment #61) > That is the joint statement of the QA lead and deputy lead, not Tomas personal > statement. That _is_ the official statement, let it be clear. > > Those who disagrees are actually invited to leave QA, for what I'm concerned. Diego, GLEP48 does not give you and Tomas such power to claim your personal opinion to be a *team* decision. Maybe the majority agree with you but still you should have brought this voting/discussion to the ML or alias before advertising it as *team* decision. If you think that QA comprises lead+co-lead, then what we ( rest of QA members ) do anyway? Just to take up space in the webpage?
The way you presented it, makes the rest of us soldiers of you and Tomas. We must obey your decisions without even discussing the issue. If this is the case, please update the GLEP48 to reflect reality
@QA: 1) Guys, you are supposed to be A TEAM. Can't you just talk to each other before slugging it out in public? 2) Whoever's job it is to enforce policies should OF COURSE personally set an example. Otherwise he's got the wrong job.
I'm adding a comment here to let everyone know that DevRel is working on this issue. We haven't "forgot it".
(In reply to comment #63) > The way you presented it, makes the rest of us soldiers of you and Tomas. We > must obey your decisions without even discussing the issue. If this is the > case, please update the GLEP48 to reflect reality Markos for one you and vapier are the reason why i left the team because otherwise i would have to kick both of you out. We are not inventing rules, (if we do they are discussed with other members), but this rule we are speaking about is decided by council, and we as QA are required to take stance where we support council without questions and enforce the policies, even if we do not agree with them and work on their revisions. If you can't understand this simple fact why the QA members are required to take such stance or you consider that such approach is bad you should just thing about removing yourself from the team too. It never was just the power to poke the tree with having to explain yourself to rest QA members. We were supposed to show that following rules is desirable and enforce them on others. And we enforce everything what we as QA and council decide without questioning (at least for others to see). I am not saying that you can disagree, but you are showing your disagreement like little child when somebody stomped on his favorite toy. You can disagree, nobody is saying otherwise, you can convince other to support your cause, you can work on the updating the things you don't like, but you CAN'T ingore the policy or support others in doing so, that is what Diego and I were saying. And FWIW leader can techincaly decide anything and just expect others to follow it, he usually just nicely discus it prior to get better insight from others, but in the end he is the one to blame for the issues so he is the one who decides, thats what the leader is supposed to do. This is the same as council operates, if we vote about something and I vote against. At the point it gets accepted I as the council member support it and just think how to improve it to make it acceptable for myself, but for all oudside people I have to support the decision. As the council decide as whole I can't just say that I didn't vote for the policy so I can ignore it. In the statement which I attached I just sumarized what we expect from every gentoo member, specialy the QA one. I didn't make up any new rules or so. So suck it up and if you don't agree you really don't have to be QA/Gentoo member. I myself tried to be one who act up-par the policies, but since our own members show serious fuzzy logic where on one side we are the guys who enforce policies and on other just ignore them I just decided I don't want to kick them out and rather removed myself.
Like I said, this was always the problem with QA. Acting as individuals instead of a team. If we were a team we could have discussed this internally first instead of make all this noise on public. Diego and I talked about this on the ML and reached a consensus. But you decided to act on your own before you even bring this issue on the QA ML or alias
You always put a "we" in front of every sentence, yet I fail to understand why. You may be absolutely right but I would like to see this discussed with the actual QA people. And I really don't like your tone or blaming me for you leaving the team just because you didn't want to discuss this issue further, and put your shiny co-lead hat and start removing cvs access from people. As you can see, GLEP48 is back on the table, just because this behavior does not look exactly right. Diego tried to talked to me before start kicking people and you decided to leave. It is far from obvious who is failing to act as a team member here. I will stop here before I lose my temper and make you open yet another devrel bug
devrel, I need a resolution here so I can weight my options of contributing to another project if forced out to repair some egos. thanks!
From not-quite affiliated point of view, I'd say it seems more and more an ego thing on all of the involved sides. Way I see it, a single developer shouldn't be allowed to arbitrarily choose which rules should they follow, regardless if they're ssuominen, vapier, arfrever or one of the less involved devs, as that creates a situation were there are effectively no rules. On the other hand, blindly applying any rules may eventually to as much trouble. How about a compromise: lets treat the current suspension as a fitting punishment and stop at that, while the accused will limit himself to complaining about this decision on every council meeting and trying to gather support for having it eventually overturned ? With "common sense" being actually a contradiction, it can't be used as criteria for deciding, which commits need to be logged. "trivial" from one point of view just too often doesn't match "trivial" from another. In such case, it's just better to log all and apply "common sense" to when/what to commit (why, yes, I kinda did contradict myself here). From user's p.o.v it's at this time far more convenient to quickly check the changelog, than to go to sources.g.o and check the commit logs. Till Gentoo moves from cvs, devs just have to live with such inconvenience. On personal note: it would be quite unfortunate, if this would become a reason for ssuominen to leave Gentoo.
Created attachment 276099 [details] DevRel resolution As today is the deadline for the 14 days of voting here is the attached resolution. I wasn't able to get a response from two members (pva, tommy) who are not devaway. I was late in submitting the final draft so at least partly my fault. The resolution still represents a majority opinion though. Peter did seem to support this text in preceding discussions. Feel free to ping me on IRC if anyone wants to discuss it.
Betelguese: is that devrel decision sufficiently binding that I can left his block?
(In reply to comment #72) > Betelguese: is that devrel decision sufficiently binding that I can left his > block? The decision is official but you should take this into account before restoring access: "Your commit access will be restored after promising to follow the policy in the future." I can also take care of restoring access if this happens.
(In reply to comment #64) sorry, but this is bunk. disagreement should be in the public view as that is how open transparent projects work. disagreement isnt something that should be viewed as "bad" and needs to be "hidden". it's simply fact that when you have more than one person, eventually there will be disagreements. also, just because there is a single team doesnt mean all of its members need to be saying the same thing. there isnt much use in an echo chamber or a herd of sheep. quite the opposite.
I can promise to not break the policy by leaving all the old files in tree and not remove anything. Unfortunately, this will likely include improving of QA and Coding Style in existing files as well (unintresting for users). That is, until the policy is sanitized again. Nothing above that is worth the effort and this way the condition of the resolution gets met.
devrel: I have lifted the block since he promises per comment 75.
(In reply to comment #66) also, just to clarify, this is factually incorrect (wrt me). at no point did i ignore the council ruling nor tell anyone else to do so. so if that's the entire basis for your leaving, well i guess that makes it a bit silly.
(In reply to comment #77) > (In reply to comment #66) > > also, just to clarify, this is factually incorrect (wrt me). at no point did i > ignore the council ruling nor tell anyone else to do so. so if that's the > entire basis for your leaving, well i guess that makes it a bit silly. true, haven't seen you removing a single ebuild since the new policy... thus not breaking the policy. never expected anyone to actually open a devrel bug about this and waste this much time. besides, i'm not leaving unless forced out, meanwhile i've completely stopped removing any files from tree until we get a sane council reverting the policy, or automate the generation on serverside.
(In reply to comment #71) > Created attachment 276099 [details] > DevRel resolution > > As today is the deadline for the 14 days of voting here is the attached > resolution. I wasn't able to get a response from two members (pva, tommy) As I mailed yesterday to devrel alias I fully support this resolution.
(In reply to comment #77) i guess i did advise someone to ignore the policy. they added a missing new line to the end of a file which had no functional impact. i.e. the last byte in the file was not a "\n" but a "}", probably because the file was edited by vim or something similar. i believe this to be an unintended side effect of the council decision which will be addressed in the next cycle. if the council did actually intend for this situation as well, then i guess feel free to start devrel proceedings. i'm sure the whole developer community will be behind that one.
(In reply to comment #76) > devrel: I have lifted the block since he promises per comment 75. Closing this bug then.
