On Mon, Aug 15, 2016 at 1:05 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
On Sat, 13 Aug 2016 02:38:13 +0530
Vivek Anand <vivekanand1101@xxxxxxxxx> wrote:
> Hi,
>
> I am one of GSoC students of this year and my project is to bring
> pkgs.fp.org <http://pkgs.fedoraproject.org/ > on a pagure instance. The
> script is almost ready but there is one issue which needs some advice.
>
> The group *provenpackagers* currently has commit rights over all the
> repositories. As you might know, in pagure if some group has commit
> rights on a repository, all the members of that group also has rights
> on the project and it's listed as their own project. This would mean
> that all the members of provenpackagers would have >18k projects of
> their own.
>
> Example:
> 1. https://admin.fedoraproject.org/pkgdb/packager/pingou/
> 2. https://pkgs.stg.fedoraproject.org/pagure/user/ pingou
>
> (it says 1119 projects, it's under investigation at the moment.)
>
> pingou came out with two ideas:
>
> *1. Drop provenpackagers from pagure: *This would mean the proven
> packagers won't get any particular advantage of shifting to pagure as
> they won't be listed as admins of all the projects in the pagure db.
> They won't be able to merge/close pull requests, edit a file directly
> via the web-interface or execute any other admin rights on any of the
> repository they wish. They would, however, have access to all the git
> repositories as they would be present in gitolite conf file. They
> would be able to push to any of the repositories as it is the case at
> present.
>
> *2. Create exception for provenpackagers:* This is hackish. We can
> give them admin rights on all the repositories but won't show them in
> their profile. (only for provenpackager group). Proven packagers will
> get all the fun on moving to pagure.
>
> pingou is inclined to go with the first option and so am i.
>
> What do you think? Does anyone have a strong preference for
> one or the other?
Well, I can see how option 1 is cleaner/easier, but I think it will
cause problems. Its going to leed to provenpackagers taking a PR and
just pushing it outside the pagure interface, which will result in not
keeping track of who wrote it, and sometimes forgetting to close it
after they do, etc.
Could we perhaps do a modified version of 2 that just adds ability to
merge PRs to all provenpackagers but doesn't do anything else?
kevin
So, apart from who can push the code to a repository, all the details about the admins is coming from the database. This means that even if we want just the ability to merge pull requests, we will have to enter the members of provenpackagers in the db. And if we are going to do that, then not showing all the repositories as their own repository for proven packager group is lot less hackish than providing them with ability to merge PRs only. The latter will result in putting checks everywhere in pagure while the former should involve only one check (although a core function of pagure).
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/ infrastructure@lists. fedoraproject.org
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
