looks like something broke on the server. please take a look when you get a chance. $ git push FATAL -- ACCESS DENIED Repo proj/pax-utils User vapier@gentoo.org Stage Before git was called Operation Repo write FATAL: W any proj/pax-utils vapier@gentoo.org DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
The ACL restricts access to toolchain@, and you're not there.
this is not a toolchain project. please fix the ACL as it was.
> owner = "Gentoo toolchain team <toolchain@gentoo.org>"
i'm glad you've identified the error. now please fix it.
toolchain: dilfridge requested the ACL update earlier today; I've asked him to clarify why, as vapier been listed as a maintainer in the README much longer (since 2005) than toolchain has (since 2020 in BUGS, 2021 in README.md).
you've been awol for 2 years and try to push changes now against the will of everyone else who took care of it. this is what you get.
Mike Frysinger has a long history of "my way or the highway" attitude towards project development. There are many historical examples of that. In the past, he repeatedly refused to follow established process and submit Portage patches for review. Instead, he demanded direct access to push changes to the repository without review. https://bugs.gentoo.org/786105 is yet another instance of the same problem. He was unwilling to follow the proper process, instead raising demands from multiple parties, only to eventually lose interest and render all the time dedicated by them lost to no effect. The toolchain team removed him through a majority vote in April 2022, given his abrasive attitude and unwillingness to follow consensus. This behavior may have been tolerated in 2005 but it is not our modus operandi in 2024.
please submit a PR/send the patches, I'm sure we can merge them with proper procedure and collaboration. taking code through review (even when write access is available) is the right thing to do. thanks!
random people who literally have never contributed to the project, either in code, or review, or in bugs, don't get to hijack a project. as Robin points out, i've literally authored this tool from the ground up (working with the original author Ned). i don't need to justify my technical choices to people who have never looked at the codebase. so restore the access to the actual author & copyright holder.
feel free to look at the git history & stats to see who is an actual author and maintainer for the project, and thus actually earned having a say in its direction. https://github.com/gentoo/pax-utils/graphs/contributors i'm not asking for membership to toolchain@. that's irrelevant to the issue at hand.
The way I see it, Gentoo is a distribution and not a code hosting for "private" Gentoo-related projects of people who just happen to be developers at the time. So I don't see why you'd claim that this is your private project and others can't maintain it. Especially given that it is a reverse dependency of important toolchain packages (sys-libs/glibc). That said, this is clearly a case of dispute. Resolving disputes is entirely out of Infrastructure team's role. Please follow the proper process for dispute resolution, and feel free to reopen the bug once you have the official approval.
i didn't say other people can't help maintain it. in fact, if you look at the history, that is clearly FUD -- other people have contributed directly and i never threw a fit that they didn't dare consult me or Ned first. historically, Ned & i specifically did not lock it down because we trusted other devs to do the right thing. cvs nor svn had ACLs. the git project had bigger team ACLs to make it easy for people to contribute. this has never been a problem as exemplified by work by Fabian, Sergei, and Sam. the reason it ended up on Gentoo infra is because public hosting wasn't huge/great back in 2003 (basically, sourceforge), and Ned & i were working on tools to benefit hardened setups (e.g. PaX). i did say that random people who have never contributed to it nor fixed a single bug do not suddenly get veto power or dictate what the actual upstream maintainers/authors of 20 years decide. it's an infra team issue because you broke ACLs without consultation or following any proper process. this is not a toolchain project, even if they were granted full write access to it to make things easier. the fact the project has been quite useful & integrated into portage is irrelevant to ownership. that's like saying everything glibc depends on is now owned by toolchain. it speaks more to the fact that the actual people writing the code have produced a good tool for 20 years in spite of what random non-devs think.
I requested the transfer and access change from Infrastructure as toolchain team lead on behalf of several team members who were strongly in favour of it. I have no stake in it myself, however, if you want to see it changed again I suggest that you talk to the other team members or comrel (in which case I will keep out of the proceedings).
that sounds like the infra team did the opposite of what Michał thinks it should have. if Michał thinks it's a dispute matter and the infra team should stay out of it, then the infra team shouldn't be removing maintainers from ACLs. if you have a concern, then you should be raising it and following the proper process (as Michał puts it), and the infra team should restore things to what they were until that is resolved.
