Hi, For Medical SIG, I would like to ask you to create following groups.
As a reference,
ASAP, when you have a time.
Regards, Jun
We don't set up koschei groups as far as I can tell. That is done by the koschei maintainers who aren't in infrastructure.
For the medical-sig, I need to know who the admin and any initial members for it.
Metadata Update from @smooge: - Issue assigned to smooge - Issue priority set to: Waiting on Assignee (was: Needs Review)
Metadata Update from @smooge: - Issue tagged with: authentication
Hi @smooge thanks for your response.
Sure. It's okay. I will contact koschei maintainers for the koschei groups.
Please set me (jaruga) as admin. The initial member is also only me. Because I would like to add other members by myself manually, asking them.
Group created and you are admin.
Metadata Update from @smooge: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
For the medical-sig, I need to know who the admin and any initial members for it. Please set me as admin. The initial member is also only me. I would like to add other members by myself manually, asking them.
Please set me as admin. The initial member is also only me. I would like to add other members by myself manually, asking them.
Just to be clear, this group isn't meant to be used to share maintenance of packages on dist-git, right?
Thanks
@smooge thanks!
@pingou thanks for pointing out this.
The group is not used to share maintenance of packages on dist-git. I meant the "medical-sig" group was like "ruby-sig" (= Group type: tracking, Prerequisite: cla_done) (= I call it non-packagers group), rather than "ruby-packagers-sig" and "rust-sig" (= Group type: pkgdb, Prerequisite: packager)(= I call it packagers group).
But what is the pros/cons of creating the non-packager group? The example that I knew was a set of "ruby-sig" (non-packagers group) and "ruby-packagers-sig" (packagers group). But if only creating a packagers group like "ruby-sig" is beneficial for us, I would like to consider moving "medical-sig" from non-packager group to packager group.
Metadata Update from @jaruga: - Issue status updated to: Open (was: Closed)
But what is the pros/cons of creating the non-packager group?
What do you want to use this group for?
You can create Koschei group yourself, by browsing to https://koschei.fedoraproject.org/add-group and submitting the form. Groups created this way are in personal user namespace, but we (sysadmin-koschei) can make them global groups - let me know once the group is created and I can make it global.
Koschei maintainers are members of Fedora Infrastructure team (sysadmin-koschei FIG).
@pingou
@mizdebsk
Thanks for the info. The operation to create the global group is documented? After I decide which kind of the FAS group I create here, I would like to create the Koschei groups, and let you know.
Okay, I take note of it.
I want to manage the packages with the sig's group account like this. You see "ruby-packages-sig" on the "members". I originally thought this operation could be later in Medical SIG. But I am okay to do it now.
This is a dist-git group so sharing the maintenance of packages to a group. I definitely requires the group to have the pre-requisite for "packager" and a few other things.
@pingou Sure. Thanks for the info.
@smooge I am sorry for my fault. Is it possible to recreate or update FAS "medical-sig" group as "packager" and do "a few other things" to achieve above thing "I want to manage the packages with the sig's group account like this."?
Smooge will confirm but I don't know that we can edit the group type or delete groups, so you may have to pick a different name.
Note that to use a group to share the maintenance of packages, that groups must have a mailing list address set in its settings and that address must be linked to a bugzilla account. The mailing list, being linked to bugzilla, may receive confidential information (such as security bugs), it is therefore advised to make the list private and monitor who is and can subscribe to it. Do you have a mailing list that would fit these criteria? If not we can create a new list for you that you will need to configure accordingly.
I don't know of a way to rename or deleting groups without breaking FAS. I think before I do anything we iron out everything that is needed and done so I don't add 2-3 more rabbit holes.
@smooge Thanks for the investigation. I am okay to keep "medical-sig" as "non-packagers".
The mailing list, being linked to bugzilla, may receive confidential information (such as security bugs), it is therefore advised to make the list private and monitor who is and can subscribe to it.
Medical SIG has this mailing list medical-sig@lists.fedorahosted.org . But I want to keep the list public like medical-sig and ruby-sig. Not private like go-sig and rust-sig.
And right now I want to go without the packager group until we Medical SIG clearly need it.
So, when we keep "medical-sig" as "non-packagers", what is the role of the non-packagers group? I do not understand the merit.
So, when we keep "medical-sig" as "non-packagers", what is the role of the non-packagers group? I does not understand the merit.
I don't know either what you wanted to use this group for, that's why I asked earlier :)
Groups can be used to: - promote contributor to CLA+1 (if there is not already a group they can join) - maintain packages collectively - get access to some resources (like the sysadmin-* groups giving access to some parts of the infrastructure)
I am likely missing some use-cases, but I think those are the most common ones.
I think before I do anything we iron out everything that is needed and done so I don't add 2-3 more rabbit holes.
I think a documentation or a template to apply the group is useful. Fedora people need to know in advance that we can not delete and edit the FAS group that we create at once.
Yeah, thanks for your consideration about it. :)
Groups can be used to: - promote contributor to CLA+1 (if there is not already a group they can join) - maintain packages collectively - get access to some resources (like the sysadmin-* groups giving access to some parts of the infrastructure) I am likely missing some use-cases, but I think those are the most common ones.
The shown use cases are helpful. Thanks.
Let me break down. What is "CLA"? How does the non-packagers group promote "maintain packages collectively"?
What is "CLA"?
It is the old word for FPCA.
How does the non-packagers group promote "maintain packages collectively"?
I don't think it does.
Ah CLA is the acronyms of Contributor License Agreement. Okay.
Okay, You just said "Groups can be used to: maintain packages collectively".
Groups created this way are in personal user namespace, but we (sysadmin-koschei) can make them global groups - let me know once the group is created and I can make it global.
I created Koschei medical-sig and biology. Could you convert those to global ones?
One question. The groups has the package list of bowtie, htslib, samtools packages as a initial list. htslib is not listed because the htslib status is untracked here. Why did this happen? How to change the status to "tracked"?
Those are the pkgdb groups which require members to be in the packager group, are then synced over to dist-git where they can be granted commit/admin access thus giving everyone in the group commit/admin access in one go.
@pingou Ah, okay. You were talking about the packager group.
Why did this happen? How to change the status to "tracked"?
@mizdebsk I found the way to enable the "Tracked by Koschei" by myself at Scheduler parameters area in the Koschei package page.
Both Koschei groups were made global.
@mizdebsk thanks! As I conformed the 2 groups are global now, I would close this ticket.
Thank you for your help to move healthcare/biotech in Fedora forward, everyone!
Metadata Update from @jaruga: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
@mizdebsk I have a question. Who can edit "medical-sig" and "biology" groups? I can edit those. But how to add people who can edit those? https://koschei.fedoraproject.org/groups
Login to comment on this ticket.