src.opensuse.org organisation mapping to Factory build service projects
Howdy, Good news. We're currently preparing a transition of devel projects to git repositories that are hosted on src.opensuse.org. For that we need to be mapping the existing factory devel projects to organisations in src.opensuse.org. organisations, unlike devel projects, are "flat". however, there is a way to group and subdivide access control in the form of teams, that are managed on organisation level but can be assigned to either orgs or repositories. Therefore there is no need to come up with a 1:1 mapping between devel projects and organisations, but rather we can do some more higher level grouping instead. This is the initial draft for your review: https://en.opensuse.org/openSUSE:ALP/Workgroups/Git-Packaging-Workflow/Proje... Please take a look and suggest changes. Either as a reply to this email or preferably, since it is a wiki, by performing the edits directly if they are deemed uncontroversial. Thanks a lot in advance, Many Greetings, Dirk -- SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nuernberg Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Hi Dirk, Dirk Müller via openSUSE Factory <factory@lists.opensuse.org> writes:
Howdy,
Good news. We're currently preparing a transition of devel projects to git repositories that are hosted on src.opensuse.org. For that we need to be mapping the existing factory devel projects to organisations in src.opensuse.org. organisations, unlike devel projects, are "flat". however, there is a way to group and subdivide access control in the form of teams, that are managed on organisation level but can be assigned to either orgs or repositories. Therefore there is no need to come up with a 1:1 mapping between devel projects and organisations, but rather we can do some more higher level grouping instead.
Thanks for this proposal!
This is the initial draft for your review:
https://en.opensuse.org/openSUSE:ALP/Workgroups/Git-Packaging-Workflow/Proje...
Please take a look and suggest changes. Either as a reply to this email or preferably, since it is a wiki, by performing the edits directly if they are deemed uncontroversial.
I would really, really like to finally get rid of the awkward split of the container ecosystem projects into Virtualization:containers, devel:kubic and devel:microos. Can we please put these three into a single namespace and not how it is done in the proposal, which imho makes matters even worse: - containers now includes Virtualization:containers, devel:kubic, a bunch of outdated stuff, and devel:{microos,kubic}:containers? So devel:microos is missing and instead there's now container images as well? - microos now includes devel:microos and a bunch of subprojects for image building. So now we still have multiple projects instead of one with the added disadvantage that image building packages are in there too. Can we please not do this? Thanks in advance, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Wed, Dec 4, 2024 at 10:51 AM Dan Čermák via openSUSE Factory <factory@lists.opensuse.org> wrote:
I would really, really like to finally get rid of the awkward split of the container ecosystem projects into Virtualization:containers, devel:kubic and devel:microos. Can we please put these three into a single namespace
devel:microos has nothing to do with containers! This is about the OS part. Please don't confuse that with devel:microos:containers! And please, don't mix container runtime with container images, we should have them in separate projects.
and not how it is done in the proposal, which imho makes matters even worse: - containers now includes Virtualization:containers, devel:kubic, a bunch of outdated stuff, and devel:{microos,kubic}:containers? So devel:microos is missing and instead there's now container images as well?
devel:microos are the tooling for MIcroOS, not for containers. Even if there are some If you want all container runtime technology in one devel project, please move them together in a new one, but don't misuse devel:microos for that.
- microos now includes devel:microos and a bunch of subprojects for image building.
Which sounds correct.
So now we still have multiple projects instead of one with the added disadvantage that image building packages are in there too. Can we please not do this?
I strongly object. Putting the MicroOS OS part (so all the tools and OS images) into one project and the containers, which are for all distributions and independent of MicroOS, into a separate project, is the right thing to do. Thorsten
Thanks in advance,
Dan
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany
www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Thorsten Kukuk <kukuk@suse.com> writes:
On Wed, Dec 4, 2024 at 10:51 AM Dan Čermák via openSUSE Factory <factory@lists.opensuse.org> wrote:
I would really, really like to finally get rid of the awkward split of the container ecosystem projects into Virtualization:containers, devel:kubic and devel:microos. Can we please put these three into a single namespace
devel:microos has nothing to do with containers! This is about the OS part. Please don't confuse that with devel:microos:containers! And please, don't mix container runtime with container images, we should have them in separate projects.
That's the theory. In practice it is the devel project of podman, buildah, nerdctl, netavark, aardvark-dns, libcontainers-common, etc.pp.
and not how it is done in the proposal, which imho makes matters even worse: - containers now includes Virtualization:containers, devel:kubic, a bunch of outdated stuff, and devel:{microos,kubic}:containers? So devel:microos is missing and instead there's now container images as well?
devel:microos are the tooling for MIcroOS, not for containers. Even if there are some If you want all container runtime technology in one devel project, please move them together in a new one, but don't misuse devel:microos for that.
We have tried to consolidate the container packages into a new project, but hit a bunch of (mostly social) problems. Also, on OBS we will inadvertently loose the commit history if we `osc copypac` them.
- microos now includes devel:microos and a bunch of subprojects for image building.
Which sounds correct.
So now we still have multiple projects instead of one with the added disadvantage that image building packages are in there too. Can we please not do this?
I strongly object. Putting the MicroOS OS part (so all the tools and OS images) into one project and the containers, which are for all distributions and independent of MicroOS, into a separate project, is the right thing to do.
I would agree with you, if the devel projects were used like originally intended. But they aren't and thus I have to disagree. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Wed, Dec 4, 2024 at 1:50 PM Dan Čermák <dcermak@suse.com> wrote:
Thorsten Kukuk <kukuk@suse.com> writes:
On Wed, Dec 4, 2024 at 10:51 AM Dan Čermák via openSUSE Factory <factory@lists.opensuse.org> wrote:
I would really, really like to finally get rid of the awkward split of the container ecosystem projects into Virtualization:containers, devel:kubic and devel:microos. Can we please put these three into a single namespace
devel:microos has nothing to do with containers! This is about the OS part. Please don't confuse that with devel:microos:containers! And please, don't mix container runtime with container images, we should have them in separate projects.
That's the theory. In practice it is the devel project of podman, buildah, nerdctl, netavark, aardvark-dns, libcontainers-common, etc.pp.
If you remove the few container runtime packages the majority of packages is still MicroOS OS specific and has nothing to do with container runtime. So podman should be separated into an own devel project.
We have tried to consolidate the container packages into a new project, but hit a bunch of (mostly social) problems. Also, on OBS we will inadvertently loose the commit history if we `osc copypac` them.
And now you get it for free :)
I strongly object. Putting the MicroOS OS part (so all the tools and OS images) into one project and the containers, which are for all distributions and independent of MicroOS, into a separate project, is the right thing to do.
I would agree with you, if the devel projects were used like originally intended. But they aren't and thus I have to disagree.
devel:microos is used like originally intended. I know for sure since Richard and I created it :) And there are more non container runtime packages than container runtime packages. Thorsten
Cheers,
Dan
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany
www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 2024-12-04, Thorsten Kukuk via openSUSE Factory <kukuk@suse.com> wrote:
On Wed, Dec 4, 2024 at 1:50 PM Dan Čermák <dcermak@suse.com> wrote:
Thorsten Kukuk <kukuk@suse.com> writes:
On Wed, Dec 4, 2024 at 10:51 AM Dan Čermák via openSUSE Factory <factory@lists.opensuse.org> wrote:
I would really, really like to finally get rid of the awkward split of the container ecosystem projects into Virtualization:containers, devel:kubic and devel:microos. Can we please put these three into a single namespace
devel:microos has nothing to do with containers! This is about the OS part. Please don't confuse that with devel:microos:containers! And please, don't mix container runtime with container images, we should have them in separate projects.
That's the theory. In practice it is the devel project of podman, buildah, nerdctl, netavark, aardvark-dns, libcontainers-common, etc.pp.
If you remove the few container runtime packages the majority of packages is still MicroOS OS specific and has nothing to do with container runtime.
So podman should be separated into an own devel project.
Or it can live in Virtualization:containers like everything else...
We have tried to consolidate the container packages into a new project, but hit a bunch of (mostly social) problems. Also, on OBS we will inadvertently loose the commit history if we `osc copypac` them.
And now you get it for free :)
I strongly object. Putting the MicroOS OS part (so all the tools and OS images) into one project and the containers, which are for all distributions and independent of MicroOS, into a separate project, is the right thing to do.
I would agree with you, if the devel projects were used like originally intended. But they aren't and thus I have to disagree.
devel:microos is used like originally intended. I know for sure since Richard and I created it :) And there are more non container runtime packages than container runtime packages.
Funnily enough, I agree this is was the original intention. The history behind these packages not being in Virtualization:containers is that they were put in devel:kubic because Richard thought that Virtualization:containers wasn't "fit" for maintaining the container runtime stuff needed for Kubic and then some of that stuff got moved to devel:microos (Richard unilaterally removing everyone from Virtualization:containers's access rights to devel:kubic a few months ago shows that this is still a sore spot for him at least). So them not being in Virtualization:containers was definitely the original intention of this project, though I'm sure that's not what you were trying to say. ;) FWIW, my view has always been that container runtimes should in principle go in Virtualization:containers, and if we're doing a re-org then it would be nice to do that now. If you're now happy with us moving those packages to Virtualization:containers, then let's go with that. (I got tired of the politics of all of this a long time ago so I would like to avoid rehashing arguments from 7 years ago if possible.) -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
On Wednesday 2024-12-04 10:27, Dirk Müller via openSUSE Factory wrote:
[for src.opensuse.org] there is a way to group and subdivide access control in the form of teams, that are managed on organisation level but can be assigned to either orgs or repositories. Therefore there is no need to come up with a 1:1 mapping between devel projects and organisations, but rather we can do some more higher level grouping instead.
This is the initial draft for your review:
https://en.opensuse.org/openSUSE:ALP/Workgroups/Git-Packaging-Workflow/Proje...
"desktop" seems a little overpopulated, but I am also curious to see teams, as described above, in practice. Maybe it's good enough. "nvdimm", "sdr" can probably be a team and joined with the hardware org, following the grouping idea of desktop.
Hi there, On Wed, 04 Dec 2024, 10:27:40 +0100, Dirk Müller via openSUSE Factory wrote:
Howdy,
Good news. We're currently preparing a transition of devel projects to git repositories that are hosted on src.opensuse.org. For that we need to be mapping the existing factory devel projects to organisations in src.opensuse.org. organisations, unlike devel projects, are "flat". however, there is a way to group and subdivide access control in the form of teams, that are managed on organisation level but can be assigned to either orgs or repositories. Therefore there is no need to come up with a 1:1 mapping between devel projects and organisations, but rather we can do some more higher level grouping instead.
call me dumb, but what will this actually mean to us developers? Will I have to maintain my sources in src.opensuse.org using git and using "osc ci" is deprecated? If so, I really don't like it... Cheers. l8er manfred
participants (6)
-
Aleksa Sarai -
Dan Čermák -
Dirk Müller -
Jan Engelhardt -
Manfred Hollstein -
Thorsten Kukuk