[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Evolving away from source package realms



On Fri, Oct 07, 2022 at 03:24:23PM +0200, Didier Raboud wrote:
> Looking at how Ubuntu is structured (with topic teams) made me wonder if some 
> variation of that couldn't reasonably be applied to Debian, by dividing our 
> giant set in subsets (topic teams, baskets, ...), under clearer team's 
> responsibilities, and onboarding processes.  That would imply that certain 
> people would have more power: [...]

Speaking only for _myself_ here: I see three drawbacks here:

1. I do upload a number of packages, quite frequently spanning across multiple teams.
   Now if you allow me to upload packages only from a bunch of teams, and also packages that
   sit in debian/ group. The process you state adds extra friction at my end to collaborate
   and adhere to more policies than I'd like to.
   My current uploading rights atleast give me the power to do emergency uploads, or upload
   when the members of a particular team are on a VAC and I _really_ need to fix something.

2. This pertains to people who seek sponsors. The current process for non-DDs is to upload
   to mentors.d.n or push to salsa and then ask a DD to upload for them. If you divide packages
   in that fashion, a sponsee will have to approach a DD from a particular team always. And if the people
   from the said team do not have the time, and some other drive-by sponsor can do so, this
   fragmentation prevents them from sponsoring a package. This makes the existing lack-of-sponsors problem even worse.

3. If members of a particular team go inactive for a while -- which is not an impossibility,
   it becomes extremely hard for someone else to join the team and/or make an upload.
   This leads to an even slower process. If you say that gaining upload permissions should
   be done at a central level, then that is still a problem since those volunteers handling permission requests
   would be bombarded with upload requests.


That being said, I am not against improving the status quo, but I feel restricting access in this
way is kinda counter-intuitive.

-- 
Best,
Nilesh

Attachment: signature.asc
Description: PGP signature


Reply to: