I call for vote revoking push access to GURU. The discussion at bug 927922 shows quite well the thoughts of many gentoo-devs and other guru contributors. Low quality ebuilds, creating packages for simple wrappers, wrong licenses, and more (many examples are linked in that bug). Multiple developers confronted him with clear intentions, much above what can be misinterpreted by any language barrier. I believe leaving access rights will result in many unmaintained low-quality ebuilds for other people to maintain, and giving wrong impression to other contributions on what is acceptable in GURU.
I vote YES
I vote Yes.
I think the people in this vote are the current members of guru-devs, meaning: > andrewammerlaan, arthurzam, ceamac, mgorny please vote.
About ebuilds quality - I am open to feedbacks, I want to have good quality ebuilds. One of the reason for me to create ebuilds - to learn how to create them. After long discussions against games under Wine - I said OK that I will not add them to Guru, if you want. For now I have no plans about new ebuilds for Guru. Anyway I want to maintain existing ebuilds - so without write access I will need to create tickets here? Sometimes I receive automatic emails that something should be fixed in existing ebuild - and I fix them. My intention to Guru (like with other services) is always to improve something, to make life better for people. I feel very sad that my good intentions and time spent to Guru ends with blocking me :(( Again, I hear you about what is bad for Guru and trying to learn. I love Gentoo and sometimes doing meetups about it. Also sometimes I contribute into the Wiki, for example I spent a lot of time writing this page https://wiki.gentoo.org/wiki/Lenovo_Thinkpad_T430 I remember my first ebuild https://github.com/gentoo/guru/tree/master/media-sound/nulloy - I spent so much time for it, even created a custom theme for that player.
I abstain. That said, since it's a self-governance matter, I think @guru-trusted should get a vote too.
I abstain and I agree that @guru-trusted should get a vote. For the future I think we should: - append to the regulations something about "reasonable maintainability" and something about "an ebuild being the sensible solution for a problem". i.e. package must do something I cannot easily accomplish with a one-liner script or by editing some config file, for example. - formalize conflict resolution policy. If there is conflict with a contributor, does @guru-trusted vote first on a solution? Do we go straight to @guru-devs? Do both vote? Do we require a formal and official warning before removal of access? We can discuss both matters elsewhere when I finish writing a more concrete proposal. As I mentioned in the other Bug, I agree with the raised concerns, but if we all agree that we do not want this then we should first write this down (and IMO issue a formal warning). For this reason, and the lack of established conflict resolution policy, I think this vote is premature.
I also agree guru-trusted should vote too. Makes sense.
Yeah, now seems logical. I also support guru-trusted voting in here.
As a guru-trusted committer: Voting Yes, at least as a temporary measure. Thoughts and perspective being: - There has been several warnings over the past weeks, including from gentoo devs - Hasn't shown much changes in behavior - A lot of the warnings have been about at-best-questionable copyright status - There's some genuine packages, for example both app-forensics/mvt and media-sound/nulloy looks good (hence why it could be temporary)
I'm also voting Yes. I don't like doing this, but here are my reasons why I'm voting yes: It's true that Vitaly has shown that he does improve his ebuilds when they are reviewed, however he will only improve technicalities on his ebuilds. When challenged on the usefulness of his ebuilds, and whether they belong in GURU, he shows a lot of resistance, even when multiple contributors and developers have expressed this, as shown in bug 927922. After a very long debate he agreed to stop putting up Wine games, but immediately put up two other ebuilds of games of similar quality (though admittedly not Wine games) and, in my opinion the straw that broke the camel's back, an *extremely* useless ebuild that should be nothing more than an alias in ~/.bashrc [0], which I reverted in [1]. Devs have tried to explain to him in bug 927922 what constitutes a useful ebuild but it is obvious that it did not get across. For this reason I am voting yes, though as Ianodan said, as a temporary measure. Vitaly: even without push access to GURU, you can still open PRs, allowing you to maintain your current (and others') ebuilds, and even propose new packages. These will need to be reviewed by someone else and merged before going in-tree. I think that is a good compromise, for now. From what I can see from your commit history you used to submit better quality and more useful ebuilds in the past, so if you return to your old ways (through PRs), then I will agree to restore push access. [0] https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=2b3560eb47f1a78a2c3480129ce104925796391e [1] https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=03c008ab93e1f23e37d5c41624cc5d5dbec5aba3
I also vote Yes. My point of view is very similar to what Julien said, and I don't think I have much to add. Vitaly doesn't seem to have malicious intentions. However, given that he failed to understand and properly address the issues presented to him, I think it is correct to revoke the access rights for the time being. As noted in other comments, the option to open PR, report bugs, and so are still available. He can still contribute to the community, and I would be glad if he keeps contributing in a way that helps the community.
Regarding the discussion on revoking Vitaly Zdanevich’s permissions, I believe we should strive for a balance between upholding strict standards and being inclusive to allow people the opportunity to learn and improve. Vitaly has expressed a willingness to receive guidance and make improvements. We should clearly specify which rules have been breached and provide concrete suggestions for improvement. This approach fosters personal development and community progress, while attracting more developers to our project. Revoking commit rights is a severe punishment, necessitating clear conditions for such penalties, like repeated community rule violations or submission of malicious software. Without these clear boundaries, I would advise against using such measures. Let’s find the right balance between clear rules and compassionate support.
I've not seen any acknowledgement that the contributions aren't really fit for google, and new packages continue to be added, is the problem.
(In reply to Sam James from comment #13) s/google/guru/...
> I've not seen any acknowledgement that the contributions aren't really fit > for ::guru I acknowledge that you do not like Wine games, ok, I will not add them. I acknowledge that you do not like one-line wrappers, ok, I will not add them. You do not want to see ISO downloading? Ok, lets people suffer when X cannot start and they need to use lynx to find the bootable ISO. > A lot of the warnings have been about at-best-questionable copyright status The copyright status is correct and valid - freeware, with license `all-rights-reserved`, for a few ebuilds. You can see all my ebuilds here https://repology.org/maintainer/zdanevich.vitaly%40ya.ru - a lot of useful stuf. Also I am proud of Organic Maps https://github.com/gentoo/guru/blob/master/gui-apps/organicmaps/organicmaps-9999.ebuild > , and new packages continue to be added, is the problem. Wow. Too many packages. Sorry for trying to be useful for the community. > Low quality ebuilds What do you mean by that, when it works? > immediately put up two other ebuilds of games of similar quality What were wrong with them?
(In reply to Vitaly Zdanevich from comment #15) > > I've not seen any acknowledgement that the contributions aren't really fit > > for ::guru > I acknowledge that you do not like Wine games, ok, I will not add them. > I acknowledge that you do not like one-line wrappers, ok, I will not add > them. > You do not want to see ISO downloading? Ok, lets people suffer when X cannot > start and they need to use lynx to find the bootable ISO. If you really want to help the community, please stop taking this as a confrontation in which one of the two sides must win and instead try to understand the underlying issue. > > > Low quality ebuilds > What do you mean by that, when it works? GURU is not a place to advertise a given program (specially unmaintained or dead ones) nor a collection of packages where one can keep throwing more stuff without care. It's an organized directory of packages in which users can rely on. Even if a program works, if the quality is very poor, it may be not correct to put it on GURU. A solution, as the devs said in the other thread, is to create an overlay.
> GURU is not a place to advertise a given program So adding ANY ebuild mean advertising it? I added many different programs. What you do not like, I do not understand?? > or a collection of packages where one can keep throwing more stuff without care. Why do you think that I do not care? Throwing? When I spent so much time doing that, learning, asking advices on Reddit and forum about how to make it work, improve, asking about code review - and now you are saying that I do not care? I do not want to contribute to this project anymore, with such a toxic attitude. I will create ebuilds FOR ME in my PRIVATE REPO. > It's an organized directory of packages in which users can rely on. And I did something against it, right? > if the quality is very poor I was open to feedbacks about the quality, I do not understand what are you talking now.
(In reply to Vitaly Zdanevich from comment #15) Your reaction and response shows that you do not understand at all the problematic here and only reinforce my opinion on voting 'yes'.
@Vitaly, please do not add new packages to GURU without prior approval from @guru-trusted. You can fix bugs, bump versions, etc, but for adding new packages you are under probation. Thank you!
(In reply to Viorel Munteanu from comment #19) > @Vitaly, please do not add new packages to GURU without prior approval from > @guru-trusted. > > You can fix bugs, bump versions, etc, but for adding new packages you are > under probation. Since your comment, app-vim/vim-mediawiki and dev-python/mwclient have been added without approval, afaik. Should I revert the offending commits?
Did not see. Created new ebuild for https://bugs.gentoo.org/197817
"Did not see." Yeah, right. Also, what part of the status RESOLVED OBSOLETE of issue 19781 was unclear?
(In reply to Vitaly Zdanevich from comment #21) > Created new ebuild for https://bugs.gentoo.org/197817 FYI, you can also open PRs on GitHub for new packages. (In reply to Ralph Seichter from comment #22) > "Did not see." Yeah, right. Also, what part of the status RESOLVED OBSOLETE > of issue 19781 was unclear? No need to be rude.
(In reply to Ralph Seichter from comment #22) > "Did not see." Yeah, right. Also, what part of the status RESOLVED OBSOLETE > of issue 19781 was unclear? I was looking for an ebuild for that benchmark, and found this old issue - why obsolete, that benchmark is still good and popular.
Considering commit https://gitweb.gentoo.org/repo/proj/guru.git/commit/?h=dev&id=79341e9f046f373509b9ab9d14ef711797d5bfa5 (some comments on github at https://github.com/gentoo/guru/commit/79341e9f046f373509b9ab9d14ef711797d5bfa5) I would like to vote "yes, revoke". Tree-wide changes need consensus before pushing and most of this commit is actually wrong, or at least "the cure is worse than the disease".
Vitaly, your continued direct commits into the ::guru repo, especially tree-wide commits, with no asking, and with much worse quality (if you have asked, I would explain to you the correct solution, since I've implemented the check and know the right way to solve it, and many others also know it). I've very liked the interactions with you in PRs, where we can improve the quality of your contributions. Others also stated it in IRC, and we were all glad. But those tree-wide commits, which are many times considered harmful (unless proven otherwise, even for experienced gentoo devs! - we consult each other for such cases and only then perform it - consensus is important in community) were a clear violation of the temporary quality improvement period. So as a fast response until further decisions, I've revoked your push permissions. Any further vote will overrule my action now - this was a contingency action.
For paper trail, I've revoked using commit id 973f30ad973357a99a8fef5765402b0ed33d5bd0 in gitolite repo (accessible to infra only).
Vitaly, let me say first that I truly appreciate your enthusiasm and commitment. That being said, we have asked you to exercise a bit more restraint with what you commit to ::guru and to ask for second opinions. Given that, stuff such as [1] is not okay. It's a tree-wide commit, touching packages that aren't yours, and it is not (properly) fixing anything. The end result is only reduced readability. Last time this came to a vote I abstained, mostly because of the lack of established conflict resolution policy. Since then we have discussed and formalized this[2]. As this policy prescribes, you have been issued a warning. You have now violated the terms of that warning and I therefore support the removal of push access. I encourage you to continue to learn and contribute via Pull Requests. [1] https://gitweb.gentoo.org/repo/proj/guru.git/commit/?h=dev&id=79341e9f046f373509b9ab9d14ef711797d5bfa5 [2] https://wiki.gentoo.org/wiki/Project:GURU#Conflict_resolution
Messing with other people's work without prior discussion and their consent is the straw that breaks the camel's back for me. I vote yes to revoke as well, if trusted contributors do indeed get a vote.
(In reply to Ralph Seichter from comment #29) > Messing with other people's work without prior discussion and their consent > is the straw that breaks the camel's back for me. I believe it's important to note that the regulations, bullet point 5, explicitly allow others to contribute improvements(!) to packages, whether they have a maintainer or not. While the regulations don't make it clear if prior discussion is necessary, that is not what caused Vitaly's access to be revoked. The problem was, as stated before by others, his continued disregard for the established rules and his problematic contributions, which kept on coming even after common mistakes had been pointed out to him. This distinction is important to me, because I fear that the GURU project would be a whole lot smaller if it wasn't for the community involvement across the repo, which I am very grateful for.
(In reply to Lucio Sauer from comment #30) > I believe it's important to note that the regulations, bullet point 5, > explicitly allow others to contribute improvements(!) to packages, whether > they have a maintainer or not. You have included the relevant emphasis already: Improvements. Also, if packages do have maintainers, I consider contacting them beforehand conditio sine qua non. I mentioned this merely as the latest in a series of reasons Vitality has provided to cause weariness regarding his interactions with the GURU repository. This song and dance has been going on for months already. @Lucio: If you wish to discuss this in more detail, although I hope I have clarified my previous comment now, feel free to contact me privately.
Indeed -- I could understand a contributor who makes a bad change to someone else's package but thought it was a good change, and didn't discuss it prior (since the rules don't explicitly state that should happen). And I would regard that as a teachable moment about what constitutes a good vs a bad change, and expect that it "shall not" happen again. There are two things about this specific case that I feel go beyond that: - it was a tree-wide change touching many packages. When making big, sweeping changes, I believe a "reasonable person's expectation" should be to double check with others before pulling the trigger, due to the magnitude. - Vitaly was on probation due to quality concerns, and should therefore have exercised caution and restraint above and beyond the normal guru process: namely, don't update packages maintained by someone else without asking them first and making sure they okay the change. If this isn't to be a condition of participation while under probation, then what exactly does a probation do? While both points are relevant here, I'm actually more concerned about the second point than the first. The first point might be a very good reason to put someone on probation -- it's the second point that I feel necessitates the revocation of commit access.
It may be worth specifically noting in the regulations that when updating a package maintained by someone else it should always be done via a PR and offering the maintainer a chance to review, but merging it yourself after a couple days even without a reply to avoid bottlenecking "good faith progress". Regardless it is irrelevant IMO to a case of probation.
Ok, sorry :(
