hm, this may be problematic as pkgdb enforces the FAS group to end with -sig.

So, this would re-purpose the existing FAS python-sig group which already receives and received potential security related bugs.

Replying to [comment:1 pingou]:

hm, this may be problematic as pkgdb enforces the FAS group to end with -sig.

So, this would re-purpose the existing FAS python-sig group which already receives and received potential security related bugs.

So in that case, what do you suggest we do?

I can see two alternatives here...

1. Just don't use a group for new folks, and add them to python-sig if they are interested in packaging and have proven themselves.

2. Pick another name for the 'intro' group. Possibles: 'pythonistas' 'fedora-python' 'pythoneers, etc

The main issue here is that Python fans want to be part of Python SIG and they wan to get into the python-sig group, but that group has some permissions in the packaging git, so we don't allow everyone and then they are disappointed that Python SIG is not for everybody.

If a packaging group has to end with sig (why?), then I's suggest:

General purpose group name: python-sig (make everybody happy)
Group with packaging permissions: python-packagers-sig or python-packaging-sig (to end with sig)

That can be done in two ways:

A) (this can only work if renaming FAS group is possible)
1. rename python-sig group and mailing list to python-packagers-sig
2. add new python-sig group

B)
1. create a new group python-packagers-sig
2. transfer all pkgdb permissions from python-sig to python-packagers-sig
3. mailing list something, not sure... ?

I think the solution proposed by kevin would be the best. My vote goes to '''fedora-python'''.

That dos not solve any of our current problems.

My thoughts were along churchyard's.

It may be just as simple to:
create a python-packagers-sig and set it in FAS
move the mailing list associated to python-sig to be associated with python-packagers-sig
move all the ACLs from python-sig to python-packagers-sig
change the tyoe of group of python-sig to not be of pkgdb type

I do think we should involve more admins from the current python-sig group at this point.

Sure, I'm fine with that plan if everyone wants to do that...

My thoughts were along churchyard's.
It may be just as simple to:
create a python-packagers-sig and set it in FAS
move the mailing list associated to python-sig to be associated with python-packagers-sig
move all the ACLs from python-sig to python-packagers-sig
change the tyoe of group of python-sig to not be of pkgdb type
I do think we should involve more admins from the current python-sig group at this point.

Whatever works best for us! +1

Primarily, I created the python-sig group to grant more people easier access to several python packages and to maintain them as a group. A rename to python-packagers-sig would more explicit express this.

+1 to the proposal from churchyard and pingou from me.

Does the packaging mailing list stay as python-sig or can it also be easy renamed?

Where can I help with the rename?

What would be the actual purpose of a python-sig intro group though? watch acl's only?

Membership tracking only (no privileges) - badges and happy members.

Membership tracking only (no privileges) - badges and happy members.

I see. I am still not sure if that could work, since no other SIGs in Fedora have taken any steps similar to what we are discussing now (from my limited research), so there isn't really an established baseline for these kind of things and their outcome.

And while unsure, I am also quite in favor of that (since also there aren't any other better alternatives proposed at the moment), because, in my opinion, this change would make things more clear and specific (with a bit of an extra maintenance burden on the SIG's admins part, in order, to manage an extra layer).

Also because of python's popularity, python-SIG attracts way more people than the other SIGs (this is just a speculation), so taking this into account, python-SIG should keep moving things forward and can also set and be a great example for other SIGs.

So from me I am +1 on churchyard's and pingou's proposal.

Shall we finalize @churchyard's and @pingou's suggestions and go ahead and make the necessary changes?

Sure. @pingou let me know what if any parts of this I can help with...

@pingou : We'll go with your and @churchyard's suggestions. Please make the necessary changes.

Ok, I created the group python-packagers-sig https://admin.fedoraproject.org/accounts/group/view/python-packagers-sig and set its owner to @tomspur since he was the owner of python-sig.

The new group will need to be configured in the same way as the old one (especially the mailing_list address).

Then I will update the ACLs in pkgdb to point to the new group.

Then a FAS admin (@nirik?) can edit the old group and change its type to tracking (instead of pkgdb) and make it require cla_done (instead of packager).

Thanks @pingou. Could you please manually copy at least the sponsors into the group, as @tomspur said he is very busy for Python SIG?

Someone with admin privileges in FAS could do it, but I do not have those :(

I have added all the sponsors from python-sig to python-packagers-sig and made them sponsors there.

Let us know when you have everything setup and we can change the type on python-sig and switch pkgdb to start using python-packagers-sig.

Thanks. I've added some more users (people I've sponsored in the past or who I know). I would gladly sponsor everybody, but in order to have some data, could the other sponsors please sponsor their sponsored users?

I just wanted to know whether the transition is complete. If it is, the python-sig group can be added as a general purpose group and new members can be allowed to join.

As it seems the python-sig FAS group requires people who apply, to be also packagers (members of the packager's group). Should this be changed?

As it seems the python-sig FAS group requires people who apply, to be also packagers (members of the packager's group). Should this be changed?

I believe it should be changed. As discussed, the python-sig will be an open group where people who would like to get involved with the SIG will be added on request.

Maybe impose that constraint on python-packagers-sig ?

Yes, thats the plan as soon as we hear that everyone desired is added to the python-packagers-sig.

Just let us know when thats done/ready and we can edit the groups and switch pkgdb to use the python-packagers-sig instead of the python-sig one.

Yes, thats the plan as soon as we hear that everyone desired is added to the python-packagers-sig.
Just let us know when thats done/ready and we can edit the groups and switch pkgdb to use the python-packagers-sig instead of the python-sig one.

Great! I'll post a reminder on the mailing list so that we can try to get this off our backs as soon as possible.

Thanks for pointing me to this here.

The onboarding process of python-sig was awful for most users. (not publicly announced, unclear what you get etc.) I could imagine, members wanted commit acls to python packages, to be able to update packages easily. That's probably one reason why I refrained from sponsoring people at all.
With the new python-packagers-sig (group), would it make sense to allow all members of that group commit access to python packages? Especially, it absolutely makes sense to change commit acls from python-sig to python-packagers-sig.

For the python-sig itself, I have no idea and unfortunately no time on working on onboarding improvement. Other than a cozy feeling to belong to "something", the SIG doesn't give anyone a benefit (yet). The same is true for a commitment of SIG members.

For the python-sig itself, I have no idea and unfortunately no time on working on onboarding improvement. Other than a cozy feeling to belong to "something", the SIG doesn't give anyone a benefit (yet). The same is true for a commitment of SIG members.

Honestly, the cozy feeling of belonging to "something" actually goes a long way to motivate for action. I'm a fairly new member of the community and I wanted to be a part of Python-SIG first, but everything was very unclear. So I later joined CommOps and now I'm trying to help Python-SIG to not lose potential contributors. We can always think of giving some benefit to the python-sig members for the tasks they do. This way the group will have some value and ultimately the members will feel valuable too.

Any news here? Is everyone desired in the python-packagers-sig group now so we can switch things in pkgdb and close this out?

:footprints:

I suggest we do it and consider the people not there yet as not interested now (and we can always add them later).

So, one further question here (sorry this has been so long a ordeal):

What do we want to do about mailing list? Should the python-packagers-sig mailing list still be 'python-sig' ? Or should we try and rename that list? Or should we make a new one?

I guess you have python-devel list for most folks? But it could be confusing to have python-sig be the initial group for the sig but also the name of the closed mailing list for the packagers.

Thoughts?

:question:

Ideally we would have python-devel@ for everyone interested and python-packagers-sig@ for python-packagers-sig members. python-sig@ should not exist.

So if it is possible to rename python-sig@ to python-packagers-sig@, I'd do it.

There are currently some automated e-mails going to python-sig@ (Bugzilla, Koji...) - I suppose they are sent because the python-sig group is a co-maintainer of involved packages and python-sig@ is set as it's e-mail address (correct?). We just need to make sure that this still works after the transition. So something like this:

1. rename mailing list python-sig@ to python-packagers-sig@
2. set python-packagers-sig@ as the e-mail address for python-packagers-sig group
3. run a script that will change all pkgdb things related to group::python-sig to group::python-packagers-sig
4. (optional) set up an e-mail redirect from python-sig@ to python-packagers-sig@

Sorry this keeps not getting done.

@abompard could you please look at renaming the python-sig list to python-packagers-sig?

Then we can do the rest and finish this off once and for all.

@abompard any news here?

Wow sorry for the delay. I'm currently running some tests to see how lists could be renamed in Mailman / HyperKitty. It's very likely that the List-Id header in emails will remain python-sig.lists.fedoraproject.org, but the email address can be changed.

FYI I'm currently hitting a couple bugs in Mailman that prevent me from renaming a list.
https://gitlab.com/mailman/mailman/issues/428

Will keep you posted.

Any news here @abompard ?

@abompard This seems to be closed upstream now with a fix

Yes, I need to update Mailman to get that fix and proceed here, but updating Mailman is more complex that it sounds like, because it now depends on Python >= 3.5.

What's wrong with Python >= 3.5?

Is it a "everything runs on RHEL7" problem, or "ansible provisioning for Python 3 apps in Fedora infra" problem? Because we can help with the first thing.

bump here. can we please get this sorted out?

This is a backlog issue and needs to get prioritized to get out of backlog. I will bring it up in the weekly meeting to see where this looks to happen.

Thanks.

@abompard was mailmain updated for this?

@churchyard is the renaming of mailing lists still something that needs to be done?

Yes, we would like to do that. It has a low priority thou (and I lost hope).

I am interested in helping with this. From reading the history it looks like the two main tasks/projects that remain are:

1. Bringing Mailman to current, which will likely involve updating python on whatever server is running Mailman.
2. Rename the mailing list.

Is this correct?

@eddiejennings item 1. is the big item here. There this ticket for updating mailman:

https://pagure.io/fedora-infrastructure/issue/8455

As I understand it, it's not an easy task.

This is still blocked by 8455.

Is this still desired? Is there any other ways forward you can think of?

Is this still desired?

I think it is, however it is not a hot topic.

Is there any other ways forward you can think of?

We could deactivate the old list and create a new one. No need to rename it.

Is this still desired?

I think it is, however it is not a hot topic.

Is there any other ways forward you can think of?

We could deactivate the old list and create a new one. No need to rename it.

Works for me.

So, to make sure I got it from re-reading:

python-sig@lists.fedoraproject.org -> close list

python-packagers-sig@lists.fedoraproject.org -> create list

python-packagers-sig -> create group / add to src.fedoraproject.org / change all packages on src.fedoraproject.org that used to refer to python-sig to refer to python-packagers-sig

adjust python-sig in account system/src.fedoraproject.org to not require packager

Did I miss anything there?

Note that python-packagers-sig already exists.

Also, bugzillas that are assigned to / cc'ed by python-sig@lists.fedoraproject.org might want to get python-packagers-sig@lists.fedoraproject.org instead before you close that list.

Other than that, I think your list is complete.

So, we came up with a plan and I managed to drop this off my radar. ;(

I'm going to really try and do it soon... this is the oldest open infra ticket. ;)

[backlog refinement]
@kevin will work on this

Gonna try and get this done. :)

Current/new plan:

[x] - python-packagers-sig@lists.fedoraproject.org -> create list
(just made this list).
[ ] - python-packagers-sig -> create group / add to src.fedoraproject.org / change all packages on src.fedoraproject.org that used to refer to python-sig to refer to python-packagers-sig
The group already exists.
I added the list to it.
I added the group to src.fedoraproject.org with churchyard already in it.

Can you please go and make a 'python-packagers-sig@lists.fedoraproject.org' bugzilla account? I set the list to moderate, so the activation emails should go to there.

Further steps after that I think are:

1. Reassign all packages that have python-sig to python-packagers-sig. Did you want to look at adding rules to the releng script we used for r-maint-sig and rust for python?
   Otherwise I can possibly do this in a db query.

2. I think a toddler will update the cc on existing bugs, but not 100% sure it will remove python-sig. We may need to run a python-bugzilla script to fix this up.

3. adjust python-sig in account system/src.fedoraproject.org to not require packager anymore.

Sorry again about this languishing.
python-sig@lists.fedoraproject.org -> close list

adjust python-sig in account system/src.fedoraproject.org to not require packager

Can you please go and make a 'python-packagers-sig@lists.fedoraproject.org' bugzilla account?

Waiting for the verification email.

Did you want to look at adding rules to the releng script we used for r-maint-sig and rust for python?

We have not yet discussed this. Python rebuilds are handled by provenpackagers from Python Maint (we have at least 5 of them), so we were not in need of that.

Can you please go and make a 'python-packagers-sig@lists.fedoraproject.org' bugzilla account?

Waiting for the verification email.

Done. The account exists now.

Great.

I think I see in the database where I can run a update and change all python-sig to python-packagers-sig. Should I just run that now? Or wait until monday/you are around/we know what we want to do with bugzilla bugs?

Once thats done, we need to deal with bugzilla. As noted it might be that a toddler will update all the open bugs to add/assign python-packagers-sig but I am not sure.
Do we want to remove python-sig from everything (even closed bugs?)
Do we want to add python-packagers-sig to everything (even closed bugs?)
Do you want me to try and do that, or do you want to?

Once thats sorted we just have:

python-sig@lists.fedoraproject.org -> close list
adjust python-sig in account system/src.fedoraproject.org to not require packager

Are all the SIG members subscribed to python-packagers-sig@lists.fedoraproject.org automatically? If not, we should probably announce this and do the transition in ~a week.

I would not bother with closed bugzillas at all.
Is removing python-sig from every bugzilla even needed?

Are all the SIG members subscribed to python-packagers-sig@lists.fedoraproject.org automatically? If not, we should probably announce this and do the transition in ~a week.

Nope. I only added you as list owner.

Note: The list should be set private, because it will get CC'ed on security bugs.
I didn't do that, but if you like I can, or you can. Just make archives private and require confirm to add new users.

I would not bother with closed bugzillas at all.
Is removing python-sig from every bugzilla even needed?

I suppose not.

I've set Archiving -> Archiving policy -> Private archives

I've set Subscription Policy -> Subscription Policy -> Confirm then Moderate

And I've mass-subscribed everybody. So I guess you can proceed with any migration of packages.

ok. Done.

Fingers crossed that it's all happy. The groups look right.

@kevin Could you see in the dist-git database if the old group is used as a default bugzilla contact somewhere?

It is:

pagure=# select * from pagure_bzoverride where epel_assignee = '@python-sig';
  id  | project_id | epel_assignee | fedora_assignee 
------+------------+---------------+-----------------
 2090 |      17733 | @python-sig   | @python-sig
 2178 |      18399 | @python-sig   | @python-sig
 2180 |      18408 | @python-sig   | @python-sig
 2230 |      18790 | @python-sig   | @python-sig
 2251 |      18955 | @python-sig   | 
(5 rows)

Those 5 are:

python-cornice
python-mglob
python-minimock
python-pyramid-chameleon
python-rxjson

Are things otherwise looking ok?

Oh, that was just epel. For fedora we have:

pagure=# select * from pagure_bzoverride where fedora_assignee = '@python-sig';
id | project_id | epel_assignee | fedora_assignee
------+------------+---------------+-----------------
2027 | 17285 | | @python-sig
2090 | 17733 | @python-sig | @python-sig
2178 | 18399 | @python-sig | @python-sig
2180 | 18408 | @python-sig | @python-sig
2193 | 18526 | | @python-sig
2230 | 18790 | @python-sig | @python-sig
2292 | 19178 | abompard | @python-sig
(7 rows)

which is:

python-cornice
python-numpydoc
python-pyramid-chameleon
pycanberra
python-mglob
python-minimock
python-tornado

Let me know if you want me to change all those to the new one.

Thank you. I've updated all of them to @python-packagers-sig except python-pyramid-chameleon which is retired on all branches. I've reset that one to the defaults.

Are things otherwise looking ok?

So far so good. Bugzilla email works. I am a bit worried that https://src.fedoraproject.org/group/python-packagers-sig only lists 3 users now until the others log out/in and some notifications might be missed due to that. Can we add the accounts from FAS manually to src.fp.o as well?

I might be able to do that via direct db, but I'm not fully sure if it does more than adds to group members. ;(
It's probibly safest to get people to login the normal way.

ok, so that leaves:

1. close the python-sig@lists.fedoraproject.org list
   Do you want to do that, or would you like me to? Or did you want to keep that list for the general (non packager) sig discussion?

2. adjust python-sig in account system/src.fedoraproject.org to not require packager.
   It seems this already happened sometime... at least I don't see the requirement currently.

close the python-sig@lists.fedoraproject.org list

Please do that. The list was only used for bugzilla.

adjust python-sig in account system/src.fedoraproject.org to not require packager

I also need to go back and read what was the plan with this FAS group :D

ok. List set to reject posts, listed as [ARCHIVED]

I think the plan was to use 'python-sig' as the group of python interested community members (for badges or whatever), but I could be wrong.

So, shall we close this out now? (finally). ?

Thank you @kevin, for finally making this happen. This can be closed.

Sorry it took so long, hopefully that will never happen again.

I've seen 3 packages with @python-sig added.

Can we block the group from being added?

I don't know if we can off hand... I suppose we could try and remove the group in the db?
but that seems bad for record keeping.

@pingou do you have any ideas here? How can we disable people adding the python-sig group to packages anymore?