[rpm-packaging][packaging][sigs] Moving to a packaging SIG
Hello folks,
It's maybe a little late, as the elections process already have started, but I think it's worth re-opening the conversation about migrating the rpm-packaging project to a SIG.
Last time we tried this, we were stopped by bureaucracy and technical details (IIRC?) which shouldn't be there anymore. I don't see a reason why this team couldn't move to a SIG now, which would be a lightweight governance model for you. You would keep your repos, and can still propose releases (if I am not mistaken). Things shouldn't change much. You can decide to change/add chair people when you want, and don't have to sign off a PTL for 6 months at elections, which was the most concerning matter for your projects IIRC (which lead to missed elections deadlines in the past).
I hope that this SIG can evolve in the future, to group not only RPM packaging, but also other packaging mechanism that want to follow under that new banner. That's why I proposed the SIG to be named "Packaging" instead. It's up to the community now to gather around the same banner :)
So if you're interested with this change, please vote on here: [1] [2].
Regards, Jean-Philippe Evrard (evrardjp)
[1]: https://review.opendev.org/752659 [2]: https://review.opendev.org/752661
Hey JP,
Last time we tried this, we were stopped by bureaucracy and technical details (IIRC?) which shouldn't be there anymore. I don't see a reason why this team couldn't move to a SIG now, which would be a lightweight governance model for you. You would keep your repos, and can still propose releases (if I am not mistaken). Things shouldn't change much. You can decide to change/add chair people when you want, and don't have to sign off a PTL for 6 months at elections, which was the most concerning matter for your projects IIRC (which lead to missed elections deadlines in the past).
This sounds good to me. you said "shouldn't change much". can you clarify if you know what actually changes other than not being in PTL-only activities? what about logistics like irc channel naming etc?
I hope that this SIG can evolve in the future, to group not only RPM packaging, but also other packaging mechanism that want to follow under that new banner. That's why I proposed the SIG to be named "Packaging" instead. It's up to the community now to gather around the same banner :)
We always collaborated with Debian-style packaging folks as far as it seemed fit, however the real collaboration overlap has always been very very small. if we have contributors with debian-style packaging interested in joining, then yes, we should use the more generic term.
Greetings, Dirk
Hi,
Hey JP,
Last time we tried this, we were stopped by bureaucracy and technical details (IIRC?) which shouldn't be there anymore. I don't see a reason why this team couldn't move to a SIG now, which would be a lightweight governance model for you. You would keep your repos, and can still propose releases (if I am not mistaken). Things shouldn't change much. You can decide to change/add chair people when you want, and don't have to sign off a PTL for 6 months at elections, which was the most concerning matter for your projects IIRC (which lead to missed elections deadlines in the past).
This sounds good to me. you said "shouldn't change much". can you clarify if you know what actually changes other than not being in PTL-only activities? what about logistics like irc channel naming etc?
I have to admit I was not very familiar with the differences between a project team and a SIG. After reading [1] and [2], I think this could work for us as a team. A SIG can own repositories, have its own IRC channel, and the accountability is reduced, since their output is not officially considered "part of the OpenStack release".
Regards, Javier
[1] - https://governance.openstack.org/tc/reference/comparison-of-official-group-s... [2] - https://governance.openstack.org/sigs/reference/sig-guideline.html
I hope that this SIG can evolve in the future, to group not only RPM packaging, but also other packaging mechanism that want to follow under that new banner. That's why I proposed the SIG to be named "Packaging" instead. It's up to the community now to gather around the same banner :)
We always collaborated with Debian-style packaging folks as far as it seemed fit, however the real collaboration overlap has always been very very small. if we have contributors with debian-style packaging interested in joining, then yes, we should use the more generic term.
Greetings, Dirk
On Fri, Sep 18, 2020, at 15:19, Javier Pena wrote:
I have to admit I was not very familiar with the differences between a project team and a SIG. After reading [1] and [2], I think this could work for us as a team. A SIG can own repositories, have its own IRC channel, and the accountability is reduced, since their output is not officially considered "part of the OpenStack release".
Hey, As you wouldn't be "part of the OpenStack release", it will change how you tag, and use the release tooling (you won't anymore). I had the impression that some freedom (and less accountability) was asked in the past (IIRC, Thomas proposed to tag by commit). That could achieve it.
Regards, JP
Jean-Philippe Evrard wrote:
As you wouldn't be "part of the OpenStack release", it will change how you tag, and use the release tooling (you won't anymore).
A precision re: release tooling -- you would still very much use the Zuul release jobs and all... You just would not go through openstack/releases and the release management team approval to actually push the tag that triggers those jobs.
Hope this clarifies :)
On Fri, Sep 18, 2020, at 15:36, Thierry Carrez wrote:
A precision re: release tooling -- you would still very much use the Zuul release jobs and all... You just would not go through openstack/releases and the release management team approval to actually push the tag that triggers those jobs.
Yup! That's what I meant. Do you think I should write something in governance to clarify this further?
Regards, JP
Jean-Philippe Evrard wrote:
[...] You would keep your repos, and can still propose releases (if I am not mistaken).
Clarification: you can still do releases (by pushing tags, as described in [1]), but the release management team is no longer responsible for them (so you're not using openstack/releases to propose them).
The choice is either: - you go with project team, deliverables considered part of the OpenStack release, you need release liaisons and accountability (PTL), and the release management team has oversight over releases or: - you go with SIG, your deliverables are considered separate from the openstack release (but still count towards "an openstack contribution" as far as governance is concerned), and you organize yourself however you want.
On Fri, Sep 18, 2020, at 15:19, Thierry Carrez wrote:
The choice is either:
- you go with project team, deliverables considered part of the
OpenStack release, you need release liaisons and accountability (PTL), and the release management team has oversight over releases or:
- you go with SIG, your deliverables are considered separate from the
openstack release (but still count towards "an openstack contribution" as far as governance is concerned), and you organize yourself however you want.
Thanks for the clarification (and confirmation), Thierry!
Regards, JP
Am Fr., 18. Sept. 2020 um 15:20 Uhr schrieb Thierry Carrez thierry@openstack.org:
Clarification: you can still do releases (by pushing tags, as described in [1]), but the release management team is no longer responsible for them (so you're not using openstack/releases to propose them).
I think we never pushed tags or tagged releases, so thats not a problem. The only support we so far needed from the release team was to create a stable branch for every release once the stable branches of OpenStack have been created.
How would that work with a SIG? Access in gerrit to create branches via the gerrit webui (which we used to do years ago) was revoked quite some time ago. Without the ability to create branches the SIG workflow would not work for us.
Thanks, Dirk
How would that work with a SIG? Access in gerrit to create branches via the gerrit webui (which we used to do years ago) was revoked quite some time ago. Without the ability to create branches the SIG workflow would not work for us.
Okay I found the documentation, we can create a separate -release team. okay, that works.
Lets go with that approach then.
Greetings, Dirk
participants (4)
-
Dirk Müller
-
Javier Pena
-
Jean-Philippe Evrard
-
Thierry Carrez