Hi,
We are currently working on getting rid of the git repo at fedora-scm-requests [1] which is nowadays only used to store the overrides of the default assignee in bugzilla (for example to allow different default assignee for Fedora and EPEL).
I am working on porting this mechanism to dist-git itself (much like we did for the anitya integration a few weeks ago).
We are thinking on providing a simple text field to submit FAS username or email to override the default assignee, the big question is then, who should be allowed to update this field ?
Should the main admin be able to set someone else as assignee ?
If there is already an override assignee, who should be allowed to change that ?
If there's no override assignee set, can everyone become it or is that up to the main admin of the component to decide and set ?
I'd appreciate your input
Thanks, Karsten
On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp karsten@redhat.com wrote:
Hi,
We are currently working on getting rid of the git repo at fedora-scm-requests [1] which is nowadays only used to store the overrides of the default assignee in bugzilla (for example to allow different default assignee for Fedora and EPEL).
I am working on porting this mechanism to dist-git itself (much like we did for the anitya integration a few weeks ago).
We are thinking on providing a simple text field to submit FAS username or email to override the default assignee, the big question is then, who should be allowed to update this field ?
Should the main admin be able to set someone else as assignee ?
If there is already an override assignee, who should be allowed to change that ?
If there's no override assignee set, can everyone become it or is that up to the main admin of the component to decide and set ?
I think in this case, it should be the main admin who can change this. If we had per-branch ACLs, then I would also say that the admins of the EPEL branches could change EPEL assignments too...
On Mon, Dec 09, 2019 at 08:46:28AM -0500, Neal Gompa wrote:
On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp karsten@redhat.com wrote:
Hi,
We are currently working on getting rid of the git repo at fedora-scm-requests [1] which is nowadays only used to store the overrides of the default assignee in bugzilla (for example to allow different default assignee for Fedora and EPEL).
I am working on porting this mechanism to dist-git itself (much like we did for the anitya integration a few weeks ago).
We are thinking on providing a simple text field to submit FAS username or email to override the default assignee, the big question is then, who should be allowed to update this field ?
Should the main admin be able to set someone else as assignee ?
If there is already an override assignee, who should be allowed to change that ?
If there's no override assignee set, can everyone become it or is that up to the main admin of the component to decide and set ?
I think in this case, it should be the main admin who can change this.
The main admin (and infra/releng) only, or all the admins of the project?
Pierre
It would be nice if we would implement "approval" system while doing this. Like if you set somebody as override, that person must click "accept". Same way to change it, the old person must click "accept".
Of course, pagure admin should be able to override this, based on FESCo tickets and such.
On Mon, Dec 9, 2019 at 3:14 PM Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Mon, Dec 09, 2019 at 08:46:28AM -0500, Neal Gompa wrote:
On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp karsten@redhat.com wrote:
Hi,
We are currently working on getting rid of the git repo at fedora-scm-requests [1] which is nowadays only used to store the overrides of the default assignee in bugzilla (for example to allow different default assignee for Fedora and EPEL).
I am working on porting this mechanism to dist-git itself (much like we did for the anitya integration a few weeks ago).
We are thinking on providing a simple text field to submit FAS username or email to override the default assignee, the big question is then, who should be allowed to update this field ?
Should the main admin be able to set someone else as assignee ?
If there is already an override assignee, who should be allowed to change that ?
If there's no override assignee set, can everyone become it or is that up to the main admin of the component to decide and set ?
I think in this case, it should be the main admin who can change this.
The main admin (and infra/releng) only, or all the admins of the project?
Pierre _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
On Mon, Dec 09, 2019 at 05:18:32PM +0100, Igor Gnatenko wrote:
It would be nice if we would implement "approval" system while doing this. Like if you set somebody as override, that person must click "accept". Same way to change it, the old person must click "accept".
I'm trying to think how this would work for groups and pseudo users. For the later this should work fine, except that potentially several people would receive the confirmation link. For the former, it's bit more tricky but it would be one way where we could ensure that the group is correctly set-up in FAS (with an mailing list address).
It's a bit more work than anticipated though, but should be doable.
Pierre
On Mon, Dec 09, 2019 at 05:35:58PM +0100, Pierre-Yves Chibon wrote:
On Mon, Dec 09, 2019 at 05:18:32PM +0100, Igor Gnatenko wrote:
It would be nice if we would implement "approval" system while doing this. Like if you set somebody as override, that person must click "accept". Same way to change it, the old person must click "accept".
I'm trying to think how this would work for groups and pseudo users. For the later this should work fine, except that potentially several people would receive the confirmation link. For the former, it's bit more tricky but it would be one way where we could ensure that the group is correctly set-up in FAS (with an mailing list address).
It's a bit more work than anticipated though, but should be doable.
Thinking some more about this and while I think we should aim for this process, considering the gain we would have from just moving away from fedora-scm-requests (nicer UX, easier sync to bugzilla of the information, no need to clone that large git repo). Would we be ok with a phased release where at first one the main admin (and infra/releng) would be able to the set the overrides?
From there we could see if we need this approval system and if we do, who can trigger changing it.
Does that sound reasonable or would you rather we land the entire change at one? (knowing that we're close to completion with Phase #1, we just need to tweak it based on the feedback we're collecting in this thread while phase #2 was not scoped at all).
Thanks for your inputs, Pierre
On Mon, Dec 09, 2019 at 06:34:15PM +0100, Pierre-Yves Chibon wrote:
On Mon, Dec 09, 2019 at 05:35:58PM +0100, Pierre-Yves Chibon wrote:
On Mon, Dec 09, 2019 at 05:18:32PM +0100, Igor Gnatenko wrote:
It would be nice if we would implement "approval" system while doing this. Like if you set somebody as override, that person must click "accept". Same way to change it, the old person must click "accept".
I'm trying to think how this would work for groups and pseudo users. For the later this should work fine, except that potentially several people would receive the confirmation link. For the former, it's bit more tricky but it would be one way where we could ensure that the group is correctly set-up in FAS (with an mailing list address).
It's a bit more work than anticipated though, but should be doable.
Thinking some more about this and while I think we should aim for this process, considering the gain we would have from just moving away from fedora-scm-requests (nicer UX, easier sync to bugzilla of the information, no need to clone that large git repo). Would we be ok with a phased release where at first one the main admin (and infra/releng) would be able to the set the overrides?
I think that would be fine and a definite improvement.
From there we could see if we need this approval system and if we do, who can trigger changing it.
Sounds good to me.
kevin
Am 09.12.19 um 18:34 schrieb Pierre-Yves Chibon:
Thinking some more about this and while I think we should aim for this process, considering the gain we would have from just moving away from fedora-scm-requests (nicer UX, easier sync to bugzilla of the information, no need to clone that large git repo). Would we be ok with a phased release where at first one the main admin (and infra/releng) would be able to the set the overrides?
From there we could see if we need this approval system and if we do, who can trigger changing it.
Does that sound reasonable or would you rather we land the entire change at one? (knowing that we're close to completion with Phase #1, we just need to tweak it based on the feedback we're collecting in this thread while phase #2 was not scoped at all).
I think that's the best way to move on from here:
Allow infra/releng and the main admin to set the overrides
We'll see if an approval system for the new assignee will be neccessary, but my guess is that a misuse by setting or removing assignees without their prior approval by other means (mail, IRC, whatever) won't happen often.
Karsten
I don't have a strong opinion, so I would start with restricted ACLs and expand if needed: site admins(releng, infra) + main admin.
2019(e)ko abenduaren 9(a) 15:07:07 (CET)-(e)an, Pierre-Yves Chibon pingou@pingoured.fr-(e)k hau idatzi zuen:
On Mon, Dec 09, 2019 at 08:46:28AM -0500, Neal Gompa wrote:
On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp karsten@redhat.com
wrote:
Hi,
We are currently working on getting rid of the git repo at
fedora-scm-requests [1] which is nowadays only used to store the overrides of the default assignee in bugzilla (for example to allow different default assignee for Fedora and EPEL).
I am working on porting this mechanism to dist-git itself (much
like we did for the anitya integration a few weeks ago).
We are thinking on providing a simple text field to submit FAS
username or email to override the default assignee, the big question is then, who should be allowed to update this field ?
Should the main admin be able to set someone else as assignee ?
If there is already an override assignee, who should be allowed to
change that ?
If there's no override assignee set, can everyone become it or is
that up to the main admin of the component to decide and set ?
I think in this case, it should be the main admin who can change
this.
The main admin (and infra/releng) only, or all the admins of the project?
Pierre _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- Julen Landa Alustiza jlanda@fedoraproject.org
We are thinking on providing a simple text field to submit FAS username or email to override the default assignee, the big question is then, who should be allowed to update this field ?
I like it's the same policy with editing the Setting page of https://src.fedoraproject.org/rpms/foo .
Should the main admin be able to set someone else as assignee ?
Yes.
If there is already an override assignee, who should be allowed to change that ?
Main admin (maintainer) + other admin people can be allowed.
If there's no override assignee set, can everyone become it or is that up to the main admin of the component to decide and set ?
First, someone can take a main admin (maintainer) for https://src.fedoraproject.org/rpms/foo . Then the person can set.
infrastructure@lists.fedoraproject.org
-
Igor Gnatenko -
Julen Landa Alustiza -
Jun Aruga -
Karsten Hopp -
Kevin Fenzi -
Neal Gompa -
Pierre-Yves Chibon