| 1 |
On 22.7.2022 22.54, Alec Warner wrote: |
| 2 |
> |
| 3 |
> I suspect this will end up being a process constraint, not a technical one. |
| 4 |
> |
| 5 |
> E.g. technically any dev can grant any contributor access to any |
| 6 |
> package (because managing thousands of fine-grained ACLs seems no |
| 7 |
> bueno to me.) |
| 8 |
> |
| 9 |
> This is fine (the same is true for anything else a developer does in ::gentoo.) |
| 10 |
|
| 11 |
So in theory yes. But you'd have to request the access from infra (and |
| 12 |
deal with gpg keys) which puts at least some sort of a barrier. |
| 13 |
|
| 14 |
In reality there's not too many of us who deal with user contributions, |
| 15 |
and I personally wouldn't start giving access to everyone who's ever |
| 16 |
contributed. Basically I was looking at these very simple packages that |
| 17 |
update sometimes multiple times a week, where the ebuild itself rarely |
| 18 |
changes. These are very "problematic" packages for us to handle because |
| 19 |
currently, and for a long time now, our "reaction" time is slower than |
| 20 |
upstream pushing updates. But I can see us extending this into trusted |
| 21 |
contributors being able to push and maintain new packages, which also |
| 22 |
have been a problematic issue for the proxy-maint project for a while now. |
| 23 |
|
| 24 |
|
| 25 |
> |
| 26 |
> So to clarify: |
| 27 |
> - We would like to make these people developers. |
| 28 |
> - Some don't want to be developers for various reasons (the quiz |
| 29 |
> being one, but there are others.) |
| 30 |
> - This is then us creating a way for those interested people to |
| 31 |
> contribute in a streamlined fashion. |
| 32 |
> |
| 33 |
|
| 34 |
That's the gist. For the 3rd point I have another POV that I opened up |
| 35 |
in my previous paragraph a bit: Getting updates to users faster, and |
| 36 |
providing new exciting packages in moderate. I'm not sure if I remember |
| 37 |
correctly, but I think discord-bin for example is a package where when |
| 38 |
upstream releases a new version, they remove the old one from their host |
| 39 |
and it's also mirror-restricted so for us the package becomes |
| 40 |
immediately broken when updated. The maintainer immediately makes a PR |
| 41 |
to update it, but it takes us multiple days to review it while no one |
| 42 |
can install the latest version from portage. With a simple |
| 43 |
mirror-restricted package like this, we could cut the wait-time. |
| 44 |
|
| 45 |
-- juippis |
Archives