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'.
