7:38 a.m.
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
[1] https://pagure.io/releng/fedora-scm-requests/
7:46 a.m.
On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp <karsten(a)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...
--
真実はいつも一つ！/ Always, there's only one truth!
8:07 a.m.
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(a)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
10:18 a.m.
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(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave(a)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.fedora...
10:35 a.m.
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
11:34 a.m.
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
2:15 p.m.
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
5:02 a.m.
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
12:29 p.m.
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(a)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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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(a)fedoraproject.org>
9:57 a.m.
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.
--
Jun | He - His - Him
1608
days inactive
1609
days old
9 comments
7 participants
participants (7)
-
Igor Gnatenko -
Julen Landa Alustiza -
Jun Aruga -
Karsten Hopp -
Kevin Fenzi -
Neal Gompa -
Pierre-Yves Chibon