please update these gentoo/ GH projects so i can manage them & releases * glibc: add toolchain team * binutils-gdb: add toolchain team * sandbox: add sandbox team * pax-utils: add me * portage-utils: add me
Could you please be more specific on what permissions you need and why? We really don't want people using GitHub beyond basic mirrors and maybe pull requests.
The available permission levels are described here: https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization
should be at least Maintain. i don't really see a problem with giving out Admin as a general thing to relevant projects, but if you want to be conservative for some unknown reason, start with Mainain.
I'm still waiting for an explanation what specifically are you going to do with that, why you need it and how's all that map into the long-term plan of avoiding anything that can't be trivially recreated until we cover GitHub with terraform or a similar solution that prevents us from losing everything the next time someone screws up.
i already said in the bug summary: to manage releases there's also other settings that are inconsistent across Gentoo GH repos that need cleaning up & disabling. the general GH management has been inconsistent at best. i fully grok that GH is not the source of truth for Gentoo code and is only for mirror purposes.
Why do you need to 'manage releases' on GitHub? And how do you propose to log your changes so that they can be restored if the repo is destroyed?
frankly, why do you care what happens ? you're not a maintainer for them. as for your concern about data loss of historical releases, we already have that problem today. Gentoo has no central hosting service for our tarballs. things make it onto distfiles.gentoo.org and then get purged when the ebuilds are removed from the tree, and often times those release tarballs get dropped as devs come & go. so unless you plan on fixing this problem that has existed since Gentoo started, GH is no different.
Actually, we host original distfiles in devspace these days, and we're looking for better solutions. I have to admit that things aren't moving really fast but then complaining doesn't improve them, neither moving a subset of files elsewhere -- in fact, d.g.o has a better chance of the files not being accidentally lost than GH.
(In reply to Michał Górny from comment #8) > d.g.o has a better chance of the files not being accidentally lost assuming you mean "dev.g.o" and not "distfiles.g.o" since the latter guarantees archives will die. dev.g.o archives still disappear (we have many examples of this), and they aren't easy to find for non-Gentoo folks. since you haven't provided any reasons to not let maintainers maintain, please grant the permissions requested and move on.
Well, I'm not convinced this should be allowed. Even if we assumed a very lax interpretation of the Social Contract here, this doesn't sound like a good idea from a pragmatic point of view. We are currently using GitHub as a git mirror. If our repositories are compromised again, we can regain access, recreate them based on data in gitolite and repush to restore the current state. We'd lose pull requests but that data is far from critical and it's something we wouldn't have had without GH anyway, so I can live with that, at least until Infra finally manages to set something up. From what I understand, you're trying to use GitHub as a origin for distfiles. If the repositories are compromised again, a third party can either replace or remove the distfiles, with the only backup being the unreliable cache on our mirrors. So to summarize, I don't think this is a good idea. It goes against the Social Contract, it goes in the opposite direction Infra's been moving for some time (i.e. reducing dependency on GitHub). If you really wish to pursue that, please ask Council to approve it. Plus possibly Trustees for SC interpretation, though I suppose the Council will do that anyway.
your interpretation of the Social Contract is wrong. GH is simply hosting an archive i created, and Gentoo infra mirrors. the fact that it started life on GH instead of dev.gentoo.org is immaterial. further, your position is completely hypocritical. you personally host multiple Gentoo projects on GH directly (not as mirrors from Gentoo), and you grab archives from them. so stop with all this BS and wasting everyone's time. pax-utils is not your project. you are not a maintainer nor author nor have any relevance here. you are only obstructing. if anything, your asinine position is just encouraging people to stop hosting their projects on Gentoo infra and do it themselves. as the maintainer & author of pax-utils, i can simply pull it off Gentoo entirely and move it to my own git server and/or GH namespace. give me the admin access to this project already.
I don't think your insults are the way to interact with other developers.
I agree with vapier here. You could say your reluctance to work with him so far led him to express himself a bit more harshly. But the problem as I see here is, shouldn't the project leads have a say who gets to manage their GH project page? Why's there apparently one person gateguarding all gentoo/* projects? Indeed this'd push people to host the project under their own account. And vapier has a point. Very hypocritical in saying everyone else should host their projects in Gentoo's infra, while, I don't see e.g. nattka there which is unarguably a very important part of Gentoo? (+ many others) So before we get our own Gitlab-instance to deal with these kinds of problems, can we just work together and have everyone get equal rights and opportunities? But then again, I'd like the project leads to ack these requests first.
(In reply to Joonas Niilola from comment #13) > I agree with vapier here. You could say your reluctance to work with him so > far led him to express himself a bit more harshly. But the problem as I see > here is, shouldn't the project leads have a say who gets to manage their GH > project page? Why's there apparently one person gateguarding all gentoo/* > projects? Indeed this'd push people to host the project under their own > account. I don't see a problem with that. The point is, gentoo/* is only for mirrors. > And vapier has a point. Very hypocritical in saying everyone else should > host their projects in Gentoo's infra, while, I don't see e.g. nattka there > which is unarguably a very important part of Gentoo? (+ many others) That is a lie. I am not hosting any of my projects in gentoo/* namespace. > So before we get our own Gitlab-instance to deal with these kinds of > problems, can we just work together and have everyone get equal rights and > opportunities? But then again, I'd like the project leads to ack these > requests first. I don't see how 'no projects hosted in gentoo/* namespace' is not equal rights. It's not like someone gets extra privileges. On the contrary, vapier seems to assume that he deserves extra privileges because he can be aggressive.
Let me rephrase. If vapier thinks we should be keeping the origins of Gentoo projects inside gentoo/* GitHub namespace, then he should discuss this publicly on the gentoo-dev mailing list and convince people. Attacking me on a bug is not a way to resolve this.
Okay, I see your POV. There still seems to be projects under gentoo/* that can't be found from our infra, although not any active ones. I guess this is something that's been recently "forced" then. What'd happen if these projects became active again? Hypotethically speaking, since vapier accounts for ~75 % of all commits, and for ~77 % of all code that's moved in the pax-utils repo, would you be willing to transfer and redirect gentoo/pax-utils to him? Then again my impression is that you can tag releases using git.gentoo.org (and write verbose notes) which are then visible and available in GH, so I don't see a huge fuss over this all. (In reply to Michał Górny from comment #15) > Attacking me on a bug is not a way to resolve this. It's true but I feel like this could've been solved before reaching that point. Now, > then he should discuss this publicly on the gentoo-dev mailing list and > convince people. Sounds like something fit for the next council's agenda. Although where was it originally decided that gentoo/* is just for mirrors? Is it a council-matter? I just want the rules to be same for everyone.
(In reply to Joonas Niilola from comment #16) > Okay, I see your POV. There still seems to be projects under gentoo/* that > can't be found from our infra, although not any active ones. I guess this is > something that's been recently "forced" then. What'd happen if these > projects became active again? This is primarily a problem of cleaning up the old repositories. Primarily depends on someone deciding where to move them, and someone doing the work. > Hypotethically speaking, since vapier accounts for ~75 % of all commits, and > for ~77 % of all code that's moved in the pax-utils repo, would you be > willing to transfer and redirect gentoo/pax-utils to him? I don't see a problem transferring the repository. > (In reply to Michał Górny from comment #15) > > Attacking me on a bug is not a way to resolve this. > > It's true but I feel like this could've been solved before reaching that > point. I've pointed that back in May, in #c10. I can't account for vapier's unwillingness to follow due process.
the goal isn't to move projects out of the Gentoo umbrella. there is no reason the project can't be hosted on Gentoo infra while also utilizing GH for features not available in Gentoo. e.g. file hosting & CI & PRs. claiming gentoo/ is "mirroring only" is a misdirect. PRs and their associated discussions aren't on Gentoo infra. that's a lot of development tracked nowhere else. same for Actions & their CI logs. your appeal for security is nonsense prima facie. you're concerned that gentoo/ GH can be compromised while simultaneously not caring if any other GH account gets compromised ? you're making up arbitrary rules all by yourself and then demanding people talk to the Council to override you. either cite previous decisions showing otherwise, or stop waving your hands.
(In reply to SpanKY from comment #18) > > you're making up arbitrary rules all by yourself Now now, there's no need to assume this. Especially after continuing with: > either cite previous decisions showing otherwise At least we can track the change to October 2019: https://wiki.gentoo.org/index.php?title=Project:GitHub/Repositories_and_mirrors&direction=next&oldid=707050 But again, and as I asked in my previous comment, it'd be nice to know where this decision came from. Was it done internally within the Github project, was infra or council related at all? Just so we know where to open correct discussion channel with. Although at this point I figure until council is involved, we're just going around the circle here. vapier you'd still have time to open discussion and include this in the next council meets agenda. Also could anyone else from the Github project weigh in here next time it's needed? Just so the replies are from the team and not perceived as personal agenda. There should be a civil and correct way in resolving this. Throwing accusations and calling names will achieve nothing in the end, except requests being ignored and comments being nitpicked. To get a decisive consistent rule I suggest taking it to council, since it's somewhat a big change and affects many active projects. Unwillingess to do so will most likely get this bug closed without any actions.
(In reply to Joonas Niilola from comment #19) thank you for your patience. that diff only says "We no longer allow original repositories in GitHub". i'm not asking for that. the projects live on git.gentoo.org and that's where i want them to remain, not under my personal GH account or personal servers. that page doesn't define what "mirror" means, but if we go with the most straight forward one (just the git state as in objects, refs, tags), i'm not asking for any of that to be different. i want those to be read-only mirrors that get clobbered if someone were to push/merge anything via GH instead of Gentoo. so i think my statement about arbitrary undocumented rules still stands, and request for citation is still pending. i don't care if i'm proven wrong, i care that it's actually clearly stated with community consensus. so please do point me at docs that i missed. i'll dig deeper and show how mgorny's claims don't make sense, or there is official documentation he is directly contradicting. "It goes against the Social Contract" as in "having a project hosted on Gentoo's git servers, mirrored to github.com/gentoo/xxx, and then attaching tarballs to it goes against the Social Contract". yet somehow deleting the project from Gentoo's git servers, and from github.com/gentoo/xxx, and hosting it in github.com/$USER/xxx *doesn't* violate the Social Contract ? the use of the code & criticality to Gentoo (e.g. ebuild package that's directly in @system) doesn't change. mgorny's own projects speak to this, including ones that he moved off of Gentoo infra, and didn't start from scratch. "Repositories get compromised and tarballs corrupted". having this be in GH/gentoo/xxx is no worse than GH/$USER/xxx, and if anything, GH/gentoo/xxx might even be better. GH/gentoo/ can enforce 2FA. there's no requirement that i set up 2FA on my own GH/$USER/ which makes it even more likely to compromise. plus, even if the tarballs do get corrupted, there's zero risk to Gentoo users. all active tarballs are mirrored on distfiles.g.o and have their sizes+hashes recorded and signed in the gentoo.git repo. if GH/gentoo/ were compromised, you'd have to hit users who weren't validating the ebuild tree, and injecting malicious tarballs would be pointless when you can just inject malicious ebuilds directly. "Repositories get compromised and tarballs lost". active tarballs are mirrored on distfiles.g.o and remain there until the corresponding ebuilds are removed. we already do not ask, let alone enforce, long term viability of archives for ebuilds not in the tree, and it's trivial to find ones that aged out and are gone forever (including ones that were posted to dev.g.o). i'm not arguing that this is a good thing, but comparatively speaking, hosting on GH is pretty reliable. i'll even point out that the Infra wiki is pretty clear that dev.g.o is **not** for hosting distfiles, and it says to **only** use the distfiles mirror. which makes GH as a hosting provider even better. > https://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Webspace#Use_and_policy > Please note that you should not store distfiles for public distribution in this space > only for distribution to other developers/testers. Packages for public distribution > should be put on the distfiles mirror. i'd be more than happy to use Gentoo self-hosted gitlab or any other service if they ever existed. we've been bemoaning lack of distfile hosting for decades, and gitlab for years. who knows if/when we'll get around to providing our own CI resources (akin to GH actions). it makes no sense to hold back projects for decades to come.
@Council: no need to read this dumpster fire if you don't want to. i sent an agenda summary to the mailing list for Oct 10th.
The Council has reached no conclusion during today's meeting and decided that the discussion needs to happen on mailing list first.
No discussion has been started.
the need hasn't gone away
(In reply to SpanKY from comment #24) > the need hasn't gone away We have a gitlab team now, and a gitlab install, please come help us port your stuff there and get everything working so we can use it; I need alpha testers to work out the details before we port all the repos ;) -A
Unccing as discussed in council meeting today (2022-05-08) as ML discussion fizzled out. Mostly blocked on gitlab I suppose, like bug 835152.
(In reply to Alec Warner from comment #25) > (In reply to SpanKY from comment #24) > > the need hasn't gone away > > We have a gitlab team now, and a gitlab install, please come help us port > your stuff there and get everything working so we can use it; I need alpha > testers to work out the details before we port all the repos ;) > > -A
Updating the summary to make this bug a bit easier to find.
