#5478 Establishing a new FAS group for Python-SIG
Opened 2 years ago by dhanesh95. Modified 2 months ago

= Phenomenon =

Establish a new FAS group '''python-packagers''' alongside '''python-sig''' with Petr Viktorin and Miro Hrončok as admins.

= Background analysis =

The CommOps team took up the task of revitalizing the on-boarding process for Python-SIG. With respect to that, the idea of establishing two FAS groups was discussed in the CommOps meeting and also on the mailing list.

= Implementation recommendation =

We are proposing to split the Python-SIG into two groups:

'''python-sig''':: For newcomers and interested members who hang out and help with Python on Fedora

'''python-packagers''':: For proven members of the community / packagers who will also receive security-related bugs. Promising members from '''python-sig''' group can be promoted to '''python-packagers''' given that they have contributed upstream.

The '''python-sig''' group already exists. We just need to create the '''python-packagers''' group with Miro Hrončok and Petr Viktorin as admins. They can work on separating the two groups / adding members / setting up mailing lists to send sensitive mails to '''python-packagers''' FAS group.


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.

Metadata Update from @smooge:
- Issue assigned to abompard

2 years ago

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.

Metadata Update from @kevin:
- Issue priority set to: Waiting on Asignee

a year ago

@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.

Login to comment on this ticket.

Metadata