[TESTERS WANTED] Using git to maintain packages on OBS - test run
Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work". FAQ: - Where can I report issues or provide feedback? https://github.com/openSUSE/scm-staging/issues (for bugs) or https://github.com/openSUSE/scm-staging/discussions (for general feedback) - Is this how the future of packaging in openSUSE is going to look like? Maybe, maybe not. This is currently just a test drive and its outcome will influence the way forward. - Will submitrequests to my develpackage still work? Sadly no, branching a git maintained package on OBS does not work. Please indicate in the description of your package that users should contribute on src.opensuse.org instead. - Which tools do I need? Just git, git-lfs and osc (at least version 1.2.0 is recommended for service runs to work) Looking forward to your feedback! Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 19. 07. 23, 11:28, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
Wow, looks great. FWIW, the first note: can we get rid of the terrible Czech translation? "Jednoduše spusťte binárku pro vaši platformu" "běží všude, kde Go může kompilovat" "Nestyďte se být přispěvatel" "Požadavky na natažení" -- really a "pull request"? Did a tartar translate the text? I assume a bot did. thanks, -- js suse labs
Hi Jiří, Jiri Slaby <jslaby@suse.cz> writes:
On 19. 07. 23, 11:28, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
Wow, looks great.
FWIW, the first note: can we get rid of the terrible Czech translation?
"Jednoduše spusťte binárku pro vaši platformu" "běží všude, kde Go může kompilovat" "Nestyďte se být přispěvatel" "Požadavky na natažení" -- really a "pull request"?
Czech translation of what? Gitea? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Dne středa 19. července 2023 12:58:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Hi Jiří,
Jiri Slaby writes:
On 19. 07. 23, 11:28, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
Wow, looks great. FWIW, the first note: can we get rid of the terrible Czech translation? "Jednoduše spusťte binárku pro vaši platformu" "běží všude, kde Go může kompilovat" "Nestyďte se být přispěvatel" "Požadavky na natažení" -- really a "pull request"?
Czech translation of what? Gitea?
Yes. I'd guess it comes from upstream. And from Google Translate... :-/ -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On Wednesday 2023-07-19 14:17, Vojtěch Zeisek wrote:
FWIW, the first note: can we get rid of the terrible Czech translation? "Jednoduše spusťte binárku pro vaši platformu" "běží všude, kde Go může kompilovat" "Nestyďte se být přispěvatel" "Požadavky na natažení" -- really a "pull request"?
Czech translation of what? Gitea?
Yes. I'd guess it comes from upstream. And from Google Translate... :-/
So what's your take? Better to have no translations or to have silly translations?
Dne středa 19. července 2023 14:35:49 CEST, Jan Engelhardt napsal(a):
On Wednesday 2023-07-19 14:17, Vojtěch Zeisek wrote:
FWIW, the first note: can we get rid of the terrible Czech translation? "Jednoduše spusťte binárku pro vaši platformu" "běží všude, kde Go může kompilovat" "Nestyďte se být přispěvatel" "Požadavky na natažení" -- really a "pull request"?
Czech translation of what? Gitea?
Yes. I'd guess it comes from upstream. And from Google Translate... :-/
So what's your take? Better to have no translations or to have silly translations?
Bit OT here, but in this case rather nothing, because the existing one is so bad that it effectively blocks understanding. But my take is reporting the issue at https://github.com/go-gitea/gitea/issues But when I see much over 2000 open issues... -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On 19/07/2023 11:28, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
Awesome. I really like the idea!
Looking forward to your feedback!
My initial feedback would be, why Gitea was chosen? I am just curious, though. There was some dispute about it after Gitea Limited was founded back in late 2022 and the paid service they offered. See [0] and [1] for more information. What about code.opensuse.org (Pagure), couldn`t that be used as well instead of src.opensuse.org? [0] https://christiantietze.de/posts/2022/11/gitea-ltd-takes-over-open-source-co... [1] https://blog.codeberg.org/codeberg-launches-forgejo.html dom -- Dominik Gedon Software Engineer SUSE Manager QE SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Hi Dominik, Dominik Gedon <dgedon@suse.de> writes:
On 19/07/2023 11:28, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
Awesome. I really like the idea!
Thanks :-)
Looking forward to your feedback!
My initial feedback would be, why Gitea was chosen? I am just curious, though. There was some dispute about it after Gitea Limited was founded back in late 2022 and the paid service they offered. See [0] and [1] for more information. What about code.opensuse.org (Pagure), couldn`t that be used as well instead of src.opensuse.org?
I must confess that I do not have all the details, but as far as I remember, the selected git forge must fulfill the following criteria: - open source (disqualifies Github) - auditable (disqualifies Gitlab due to its sheer size) - maintained (sadly disqualifies pagure, it's been unmaintained since Pingou was pulled of that project a few years back) and thus we ended up with gitea. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 19.07.23 at 13:53 Dan Čermák via openSUSE Factory wrote:
I must confess that I do not have all the details, but as far as I remember, the selected git forge must fulfill the following criteria:
- open source (disqualifies Github) - auditable (disqualifies Gitlab due to its sheer size) - maintained (sadly disqualifies pagure, it's been unmaintained since Pingou was pulled of that project a few years back)
and thus we ended up with gitea.
In case the issue with Gitea Ltd. causes headaches, that is why Forgejo was forked. It is a drop-in-replacement for Gitea with currently compatible setup. Just FYI. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Wed, Jul 19, 2023 at 7:53 AM Dan Čermák via openSUSE Factory <factory@lists.opensuse.org> wrote:
Hi Dominik,
Dominik Gedon <dgedon@suse.de> writes:
On 19/07/2023 11:28, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
Awesome. I really like the idea!
Thanks :-)
Looking forward to your feedback!
My initial feedback would be, why Gitea was chosen? I am just curious, though. There was some dispute about it after Gitea Limited was founded back in late 2022 and the paid service they offered. See [0] and [1] for more information. What about code.opensuse.org (Pagure), couldn`t that be used as well instead of src.opensuse.org?
I must confess that I do not have all the details, but as far as I remember, the selected git forge must fulfill the following criteria:
- open source (disqualifies Github) - auditable (disqualifies Gitlab due to its sheer size) - maintained (sadly disqualifies pagure, it's been unmaintained since Pingou was pulled of that project a few years back)
and thus we ended up with gitea.
Pagure is maintained. We have new contributions coming in and work going on to make Pagure 6.0. There's going to be a talk at Flock about it. -- 真実はいつも一つ！/ Always, there's only one truth!
On Wednesday 2023-07-19 13:45, Dominik Gedon wrote:
My initial feedback would be, why Gitea was chosen? I am just curious, though.
Gitea looks more like Github [https://gitlab.freedesktop.org/gstreamer/gstreamer/] with navigation presented at the top as sort of notebook pages. GitLab [https://gitlab.freedesktop.org/gstreamer/gstreamer/], the navigation is a mix of left-hand side menu full of suboptions but also a breadcrumb bar. Feels like they don't really know what they want.
Dne středa 19. července 2023 14:46:04 CEST, Jan Engelhardt napsal(a):
On Wednesday 2023-07-19 13:45, Dominik Gedon wrote:
My initial feedback would be, why Gitea was chosen? I am just curious, though.
Gitea looks more like Github [https://gitlab.freedesktop.org/gstreamer/gstreamer/] with navigation presented at the top as sort of notebook pages.
GitLab [https://gitlab.freedesktop.org/gstreamer/gstreamer/], the navigation is a mix of left-hand side menu full of suboptions but also a breadcrumb bar. Feels like they don't really know what they want.
Recently, when we were thinking if to install GitLab (finally yes), I was thinking also about GitBucket <https://gitbucket.github.io/> and RhodeCode <https://rhodecode.com/> -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try. But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change? thanks, Takashi
FAQ:
- Where can I report issues or provide feedback? https://github.com/openSUSE/scm-staging/issues (for bugs) or https://github.com/openSUSE/scm-staging/discussions (for general feedback)
- Is this how the future of packaging in openSUSE is going to look like? Maybe, maybe not. This is currently just a test drive and its outcome will influence the way forward.
- Will submitrequests to my develpackage still work? Sadly no, branching a git maintained package on OBS does not work. Please indicate in the description of your package that users should contribute on src.opensuse.org instead.
- Which tools do I need? Just git, git-lfs and osc (at least version 1.2.0 is recommended for service runs to work)
Looking forward to your feedback!
Dan
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany
(HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi Takashi, Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try.
But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory). Hope this answers your questions, Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Takashi Iwai writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try. But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be? -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
Hi, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> writes:
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Takashi Iwai writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try. But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well. However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On Wed, 19 Jul 2023 15:04:45 +0200, Dan Čermák via openSUSE Factory wrote:
Hi,
Vojtěch Zeisek <vojtech.zeisek@opensuse.org> writes:
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Takashi Iwai writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try. But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing. The scenario above doesn't imply any functional test is done, and yet it'll be submitted straightly to FACTORY for production? Takashi
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:04:45 +0200, Dan Čermák via openSUSE Factory wrote:
Hi,
Vojtěch Zeisek <vojtech.zeisek@opensuse.org> writes:
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Takashi Iwai writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try. But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
The scenario above doesn't imply any functional test is done, and yet it'll be submitted straightly to FACTORY for production?
Well, the scenario doesn't prevent you from testing your build locally before creating a pull request. We could extend the bot to create a project & package for all pull requests and only submit it if the pull request is not a draft. Would that help? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/19/23 22:48, Dan Čermák via openSUSE Factory wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:04:45 +0200, Dan Čermák via openSUSE Factory wrote:
Hi,
Vojtěch Zeisek <vojtech.zeisek@opensuse.org> writes:
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Takashi Iwai writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote: > Dear packagers for openSUSE Tumbleweed, > we have been working on a prototype that allows you to maintain your > packages in git (similarly to Fedora's dist git) on src.opensuse.org > instead of on OBS. Contributions to the package are then handled via > pull requests on src.opensuse.org which get automatically forwarded > as submitrequests on OBS. > This is currently just a prototype and we are looking for testers > and general feedback. So if you want to participate as a maintainer, > please check the full guide here: > https://opensuse.github.io/scm-staging/user_guide.html > tl;dr; you'll have to convert the develpackage to use `<scmsync>` > from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try. But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
The scenario above doesn't imply any functional test is done, and yet it'll be submitted straightly to FACTORY for production?
Well, the scenario doesn't prevent you from testing your build locally before creating a pull request.
We could extend the bot to create a project & package for all pull requests and only submit it if the pull request is not a draft. Would that help?
Traditionally with a project like enlightenment, I will push a new version of the libraries to the devel project, then boot up a virtual machine to do a basic smoke test that the desktop, libraries and other applications all function together nicely before pushing to tumbleweed in my eyes this was the point of the devel project. I could instead branch all those packages into a home or some other project and use that for testing but this new workflow seems to go against the idea of devel projects that in many cases are quite useful unless I'm missing something. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hi Simon, Simon Lees <sflees@suse.de> writes:
On 7/19/23 22:48, Dan Čermák via openSUSE Factory wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:04:45 +0200, Dan Čermák via openSUSE Factory wrote:
Hi,
Vojtěch Zeisek <vojtech.zeisek@opensuse.org> writes:
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Takashi Iwai writes: > On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote: >> Dear packagers for openSUSE Tumbleweed, >> we have been working on a prototype that allows you to maintain your >> packages in git (similarly to Fedora's dist git) on src.opensuse.org >> instead of on OBS. Contributions to the package are then handled via >> pull requests on src.opensuse.org which get automatically forwarded >> as submitrequests on OBS. >> This is currently just a prototype and we are looking for testers >> and general feedback. So if you want to participate as a maintainer, >> please check the full guide here: >> https://opensuse.github.io/scm-staging/user_guide.html >> tl;dr; you'll have to convert the develpackage to use `<scmsync>` >> from src.opensuse.org/pool and everything else should "just work". > > This looks awesome, I'd love to give it a try. > But, maybe because I have no clear "big picture" yet, I don't see how > it fits with the actual package development work. Usually, a package > is branched to home:$user:branches:$develproj, patched there, built, > tested, then finally submitted to $develproj (which goes eventually to > FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
The scenario above doesn't imply any functional test is done, and yet it'll be submitted straightly to FACTORY for production?
Well, the scenario doesn't prevent you from testing your build locally before creating a pull request.
We could extend the bot to create a project & package for all pull requests and only submit it if the pull request is not a draft. Would that help?
Traditionally with a project like enlightenment, I will push a new version of the libraries to the devel project, then boot up a virtual machine to do a basic smoke test that the desktop, libraries and other applications all function together nicely before pushing to tumbleweed in my eyes this was the point of the devel project.
I could instead branch all those packages into a home or some other project and use that for testing but this new workflow seems to go against the idea of devel projects that in many cases are quite useful unless I'm missing something.
This initial prototype is indeed intentionally (more or less) bypassing devel projects and is thus at the moment not suitable for your envisioned use case. We are more looking to improve the workflow of maintainers of single packages, that would just submit their locally tested package to Factory. Since we have no great solution how to maintain a project or product in git, we have decided to defer this issue for now and first try to tackle the simpler case where we just focus on single packages. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/19/23 23:53, Dan Čermák via openSUSE Factory wrote:
Hi Simon,
Simon Lees <sflees@suse.de> writes:
On 7/19/23 22:48, Dan Čermák via openSUSE Factory wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:04:45 +0200, Dan Čermák via openSUSE Factory wrote:
Hi,
Vojtěch Zeisek <vojtech.zeisek@opensuse.org> writes:
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a): > Takashi Iwai writes: >> On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote: >>> Dear packagers for openSUSE Tumbleweed, >>> we have been working on a prototype that allows you to maintain your >>> packages in git (similarly to Fedora's dist git) on src.opensuse.org >>> instead of on OBS. Contributions to the package are then handled via >>> pull requests on src.opensuse.org which get automatically forwarded >>> as submitrequests on OBS. >>> This is currently just a prototype and we are looking for testers >>> and general feedback. So if you want to participate as a maintainer, >>> please check the full guide here: >>> https://opensuse.github.io/scm-staging/user_guide.html >>> tl;dr; you'll have to convert the develpackage to use `<scmsync>` >>> from src.opensuse.org/pool and everything else should "just work". >> >> This looks awesome, I'd love to give it a try. >> But, maybe because I have no clear "big picture" yet, I don't see how >> it fits with the actual package development work. Usually, a package >> is branched to home:$user:branches:$develproj, patched there, built, >> tested, then finally submitted to $develproj (which goes eventually to >> FACTORY). With the git workflow, how does it change? > > We are experimenting with a workflow that is less > devel-project-centric. The currently anticipated workflow to contribute > to $pkg looks as follows: > - you fork the package in src.opensuse.org/pool/$pkg > - you implement your changes and submit a pull request against the > repository in pool/$pkg > - a bot will create a submission from a new project on OBS to > openSUSE:Factory directly with your modifications > - if the SR to Factory is accepted, then the bot will merge the pull > request > The develproject is still there, it builds whatever is currently in > src.opensuse.org/pool/$pkg (that should be however more or less exactly > what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
The scenario above doesn't imply any functional test is done, and yet it'll be submitted straightly to FACTORY for production?
Well, the scenario doesn't prevent you from testing your build locally before creating a pull request.
We could extend the bot to create a project & package for all pull requests and only submit it if the pull request is not a draft. Would that help?
Traditionally with a project like enlightenment, I will push a new version of the libraries to the devel project, then boot up a virtual machine to do a basic smoke test that the desktop, libraries and other applications all function together nicely before pushing to tumbleweed in my eyes this was the point of the devel project.
I could instead branch all those packages into a home or some other project and use that for testing but this new workflow seems to go against the idea of devel projects that in many cases are quite useful unless I'm missing something.
This initial prototype is indeed intentionally (more or less) bypassing devel projects and is thus at the moment not suitable for your envisioned use case. We are more looking to improve the workflow of maintainers of single packages, that would just submit their locally tested package to Factory.
Since we have no great solution how to maintain a project or product in git, we have decided to defer this issue for now and first try to tackle the simpler case where we just focus on single packages.
No problems, I can wait to see what you come up with before testing. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Am Mittwoch, 19. Juli 2023, 15:10:31 CEST schrieb Takashi Iwai:
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
Totally agree. I create my packages locally. Sometimes several for program. Then they have to be uploaded. And I test every package first at my place or in a VM. Only then it goes to devel or factory. Now everything is automatically sent to factory? Whether it has errors or not? But the sense is not clear to me. At all. What is this supposed to do to make my work easier or save me time? I have to download everything from OBS, test it and upload it. Then the whole thing again in gitea? For me, the workload and the time required is doubled. Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 19. Juli 2023, 15:10:31 CEST schrieb Takashi Iwai:
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
Totally agree. I create my packages locally. Sometimes several for program. Then they have to be uploaded. And I test every package first at my place or in a VM. Only then it goes to devel or factory. Now everything is automatically sent to factory? Whether it has errors or not? But the sense is not clear to me. At all. What is this supposed to do to make my work easier or save me time? I have to download everything from OBS, test it and upload it. Then the whole thing again in gitea?
No, the point is that you can keep your sources in git completely and don't have to mess with OBS at all. You as a contributor only have to fork & commit in gitea, the forwarding to OBS is done for you by the bot. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am 19. Juli 2023 16:17:18 MESZ schrieb "Dan Čermák via openSUSE Factory" <factory@lists.opensuse.org>:
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 19. Juli 2023, 15:10:31 CEST schrieb Takashi Iwai:
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
Totally agree. I create my packages locally. Sometimes several for program. Then they have to be uploaded. And I test every package first at my place or in a VM. Only then it goes to devel or factory. Now everything is automatically sent to factory? Whether it has errors or not? But the sense is not clear to me. At all. What is this supposed to do to make my work easier or save me time? I have to download everything from OBS, test it and upload it. Then the whole thing again in gitea?
No, the point is that you can keep your sources in git completely and don't have to mess with OBS at all. You as a contributor only have to fork & commit in gitea, the forwarding to OBS is done for you by the bot.
I can't shake the feeling that somehow people don't understand how a package is built. Or maybe I am too conscientious. The following procedure for a package change. 1. package branches. 2. check out the package 3. change package 4. check in the package. 5. see if it is built error-free for Leap and Tumbleweed. 6. install and test package. 7. if i.o send a request. So what's the point of git for me? I make a change and then a push. Whether it builds I don't know, whether it works I don't know. After me the flood of meaning And how should a request be sent then? Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am 19. Juli 2023 16:17:18 MESZ schrieb "Dan Čermák via openSUSE Factory" <factory@lists.opensuse.org>:
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 19. Juli 2023, 15:10:31 CEST schrieb Takashi Iwai:
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
Totally agree. I create my packages locally. Sometimes several for program. Then they have to be uploaded. And I test every package first at my place or in a VM. Only then it goes to devel or factory. Now everything is automatically sent to factory? Whether it has errors or not? But the sense is not clear to me. At all. What is this supposed to do to make my work easier or save me time? I have to download everything from OBS, test it and upload it. Then the whole thing again in gitea?
No, the point is that you can keep your sources in git completely and don't have to mess with OBS at all. You as a contributor only have to fork & commit in gitea, the forwarding to OBS is done for you by the bot.
I can't shake the feeling that somehow people don't understand how a package is built. Or maybe I am too conscientious.
The following procedure for a package change.
1. package branches. 2. check out the package 3. change package 4. check in the package. 5. see if it is built error-free for Leap and Tumbleweed. 6. install and test package. 7. if i.o send a request.
So what's the point of git for me?
You don't have to interact with OBS version control and can rely on git.
I make a change and then a push.
Whether it builds I don't know, whether it works I don't know.
You do know that. The bot reports the build status back on src.opensuse.org as a commit status check with a link to the created package.
After me the flood of meaning
No.
And how should a request be sent then?
The request will be sent automatically for you when you open a pull request against the package in pool/. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am 19. Juli 2023 16:35:01 MESZ schrieb "Dan Čermák" <dcermak@suse.com>:
Eric Schirra <ecsos@opensuse.org> writes:
Am 19. Juli 2023 16:17:18 MESZ schrieb "Dan Čermák via openSUSE Factory" <factory@lists.opensuse.org>:
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 19. Juli 2023, 15:10:31 CEST schrieb Takashi Iwai:
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
I'm afraid that this flow is problematic. From the maintainer POV, each submission is supposed to be already fully tested -- both from package builds *and* functionality. Many (most of?) functional tests can't be done in a CI, and needs manual testing.
Totally agree. I create my packages locally. Sometimes several for program. Then they have to be uploaded. And I test every package first at my place or in a VM. Only then it goes to devel or factory. Now everything is automatically sent to factory? Whether it has errors or not? But the sense is not clear to me. At all. What is this supposed to do to make my work easier or save me time? I have to download everything from OBS, test it and upload it. Then the whole thing again in gitea?
No, the point is that you can keep your sources in git completely and don't have to mess with OBS at all. You as a contributor only have to fork & commit in gitea, the forwarding to OBS is done for you by the bot.
I can't shake the feeling that somehow people don't understand how a package is built. Or maybe I am too conscientious.
The following procedure for a package change.
1. package branches. 2. check out the package 3. change package 4. check in the package. 5. see if it is built error-free for Leap and Tumbleweed. 6. install and test package. 7. if i.o send a request.
So what's the point of git for me?
You don't have to interact with OBS version control and can rely on git.
I make a change and then a push.
Whether it builds I don't know, whether it works I don't know.
You do know that. The bot reports the build status back on src.opensuse.org as a commit status check with a link to the created package.
After me the flood of meaning
No.
And how should a request be sent then?
The request will be sent automatically for you when you open a pull request against the package in pool/.
But that takes a lot more time. Considerably more. I have to wait until I get a result at some point. But I don't have time for that. It has to go like clockwork. And an error is then "up" for the time being. Until I get feedback and until I find time to do something again. So. The question again. What does git save or make easier? Regards Eric
Maybe I've not understood everything, but what about using the current workflow but with git branches? People can PR to devel branch and it gets submitted as an SR to the devel project. Then the maintainer can PR devel -> factory and the SR gets submitted to factory. With this config: devel branch --> devel project factory branch --> factory SR to devel projects should also be disallowed in this case, so that the only source of truth is git. Regards, Eyad
Hi Eyad, Am Do., 20. Juli 2023 um 13:49 Uhr schrieb <eyadlorenzo@gmail.com>:
Maybe I've not understood everything, but what about using the current workflow but with git branches?
It means that you have two PR/MRs that are unrelated and it doesn't fix the current problem that devel project maintainer accepts something that then gets rejected in the factory review (bots or humans). the improvement comes from having all the reviews happening in one PR that starts with the change and ends with the change ending in factory. Greetings, Dirk
On 7/20/23 07:59, Dirk Müller wrote:
Hi Eyad,
Am Do., 20. Juli 2023 um 13:49 Uhr schrieb <eyadlorenzo@gmail.com>:
Maybe I've not understood everything, but what about using the current workflow but with git branches?
It means that you have two PR/MRs that are unrelated and it doesn't fix the current problem that devel project maintainer accepts something that then gets rejected in the factory review (bots or humans). the improvement comes from having all the reviews happening in one PR that starts with the change and ends with the change ending in factory.
But who does the review? Today only factory reviewers have the permissions to accept into Factory. This, today makes the assumption that somewhere in the devel project there was a review by a person that is an "expert" for a given package. Now granted we have many packages that do not require special attention. But we also have many packages that do require special attention. So how do we get those packages that do require special attention reviewed by the people that have the most insight into those packages. For example we should always have a botocore, boto3 and aws-cli submission pretty much at the same time and not a random botocore update. How do we prevent the "drive by" botocore update if that request does not get reviewed by the people that know that the packages should always go together? Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX rjschwei@suse.com IRC: robjo
Hi Eyad, eyadlorenzo@gmail.com writes:
Maybe I've not understood everything, but what about using the current workflow but with git branches?
This could be a second step indeed and is also something that we were thinking about.
People can PR to devel branch and it gets submitted as an SR to the devel project. Then the maintainer can PR devel -> factory and the SR gets submitted to factory.
This is problematic, as currently submissions to Factory are 100% reliant on checkers based on submit requests. However, with git based packages, submit requests cease to work. For that we would have to migrate all the tooling that currently runs the staging projects and checks the results to a git based workflow. This is on the roadmap, but it's a bit further in the future and depends on too many unknowns at the moment. The reliance of Factory submissions on submit requests is also the reason why the bot currently creates submit requests from pull requests: to allow all the tooling for release engineering to continue to work.
With this config: devel branch --> devel project factory branch --> factory
SR to devel projects should also be disallowed in this case, so that the only source of truth is git.
SRs to the devel project cease to work once you switch to scmsync anyway. OBS will report an error if you try to branch such a package. So this shouldn't be a problem. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi Dan and thank you for your reply! Il 20/07/23 13:59, Dan Čermák ha scritto:
This is problematic, as currently submissions to Factory are 100% reliant on checkers based on submit requests. However, with git based packages, submit requests cease to work. For that we would have to migrate all the tooling that currently runs the staging projects and checks the results to a git based workflow.
Even if said PR from pool/<proj>:devel to pool/<proj>:factory gets converted to a SR from devel:<proj> to Factory:<proj> ? Wouldn't the tools then be able to test the SR as they are tested now? Regards, Eyad
Hi Eyad, Eyad Issa <eyadlorenzo@gmail.com> writes:
Hi Dan and thank you for your reply!
Il 20/07/23 13:59, Dan Čermák ha scritto:
This is problematic, as currently submissions to Factory are 100% reliant on checkers based on submit requests. However, with git based packages, submit requests cease to work. For that we would have to migrate all the tooling that currently runs the staging projects and checks the results to a git based workflow.
Even if said PR from pool/<proj>:devel to pool/<proj>:factory gets converted to a SR from devel:<proj> to Factory:<proj> ?
That would be possible, but then the git repositories' factory branch would no longer be the single source of truth. I am pretty certain there will be edge cases where the state in Factory (on OBS) would then diverge from the git repository.
Wouldn't the tools then be able to test the SR as they are tested now?
Yes, but with the above catch, I don't see how to achieve this. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi, On 7/19/23 09:04, Dan Čermák via openSUSE Factory wrote:
Hi,
Vojtěch Zeisek <vojtech.zeisek@opensuse.org> writes:
Dne středa 19. července 2023 14:14:44 CEST, Dan Čermák via openSUSE Factory napsal(a):
Takashi Iwai writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed, we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS. This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try. But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows: - you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
This testing phase will be created by the bot once you submit a pull request on src.opensuse.org. It creates a new project from your pull request. It will also reuse the repository setup from the devel project on OBS, so you can check for build failures there as well.
However, it will automatically submit your package to Factory, so this testing phase might be a bit shorter.
Hmm that would appears to exacerbate the problem of some people overstepping. How do we ensure we get reviews in place for those packages that not easily work with "drive by" submissions? Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX rjschwei@suse.com IRC: robjo
Hi Vojtech, Am Mi., 19. Juli 2023 um 14:26 Uhr schrieb Vojtěch Zeisek <vojtech.zeisek@opensuse.org>:
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
It is git, you can branch it wherever you want. The workflow is currently not prescribing you to a particular model. you're free to setup a home/playground/staging project that syncs from a different git organization or branch. Greetings, Dirk
On 2023-07-19, 12:26 GMT, Vojtěch Zeisek wrote:
I might be missing something, but in my home OBS repo I can play with package, test if it build correctly for everything etc. And submit when satisfied. Where will this "testing" phase be?
Yes, you can do the same. When you checkout the package via `osc checkout` (following the manual, or if you help me to debug git obranch script from https://src.opensuse.org/mcepl_tools/gosc/src/branch/master/git-obranch) you get completely working OBS checkout, so you can use osc build as if nothing has changed. Best, Matěj -- https://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 No matter what happens in the kitchen, never apologize. -- Julia Child
On Wed, 19 Jul 2023 14:14:44 +0200, Dan Čermák wrote:
Hi Takashi,
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try.
But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows:
- you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request
The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
Hope this answers your questions,
Hmm. Before doing a PR, you'll need to build and test a package. And, that's done in OBS home:*:branches:* in the past. That is, the branched develproject itself was a test bench. So, what's not clear to me is, in the flow above:
1. you fork the package in src.opensuse.org/pool/$pkg 2a. you implement your changes 2b. and submit a pull request against the repository in pool/$pkg
between 2a and 2b, you need the package build and test. But how would it be done? thanks, Takashi
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 14:14:44 +0200, Dan Čermák wrote:
Hi Takashi,
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try.
But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows:
- you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request
The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
Hope this answers your questions,
Hmm. Before doing a PR, you'll need to build and test a package. And, that's done in OBS home:*:branches:* in the past. That is, the branched develproject itself was a test bench. So, what's not clear to me is, in the flow above:
1. you fork the package in src.opensuse.org/pool/$pkg 2a. you implement your changes 2b. and submit a pull request against the repository in pool/$pkg
between 2a and 2b, you need the package build and test. But how would it be done?
Local builds should still be possible, so you can build and test it locally. Otherwise, you can also create a pull request and use the project that the bot created for testing, albeit with the catch that it will submit your package to Factory. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On Wed, 19 Jul 2023 15:08:11 +0200, Dan Čermák wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 14:14:44 +0200, Dan Čermák wrote:
Hi Takashi,
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try.
But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows:
- you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request
The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
Hope this answers your questions,
Hmm. Before doing a PR, you'll need to build and test a package. And, that's done in OBS home:*:branches:* in the past. That is, the branched develproject itself was a test bench. So, what's not clear to me is, in the flow above:
1. you fork the package in src.opensuse.org/pool/$pkg 2a. you implement your changes 2b. and submit a pull request against the repository in pool/$pkg
between 2a and 2b, you need the package build and test. But how would it be done?
Local builds should still be possible, so you can build and test it locally.
But I don't build the whole architectures and repos locally. I suppose one can still commit to a branched project, build/test it, then it's synced to git src.o.o and git-PR? Is it the expected way?
Otherwise, you can also create a pull request and use the project that the bot created for testing, albeit with the catch that it will submit your package to Factory.
Yes, and that's my concern -- the build and integration test isn't done before submission unlike the current workflow with OBS. I believe (or hope) that FACTORY submission will check more strictly about the build status of the project created by bot, but the PR to devel project needs the testing at first, too. Takashi
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:08:11 +0200, Dan Čermák wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 14:14:44 +0200, Dan Čermák wrote:
Hi Takashi,
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try.
But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows:
- you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request
The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
Hope this answers your questions,
Hmm. Before doing a PR, you'll need to build and test a package. And, that's done in OBS home:*:branches:* in the past. That is, the branched develproject itself was a test bench. So, what's not clear to me is, in the flow above:
1. you fork the package in src.opensuse.org/pool/$pkg 2a. you implement your changes 2b. and submit a pull request against the repository in pool/$pkg
between 2a and 2b, you need the package build and test. But how would it be done?
Local builds should still be possible, so you can build and test it locally.
But I don't build the whole architectures and repos locally. I suppose one can still commit to a branched project, build/test it, then it's synced to git src.o.o and git-PR? Is it the expected way?
No, as I wrote in the FAQ, branching a package on OBS will no longer work once you use scmsync. This is a design limitation in OBS: a package relying on scmsync is synchronized just one way git -> OBS. OBS pulls the git repository and imports it into its own version control. Hence if you would create a submitrequest on such a package, you couldn't accept it anyway as that would yield inconsistent states between OBS and git. The only ways out of this issue are either to forbid submitrequests or to teach OBS to talk git natively.
Otherwise, you can also create a pull request and use the project that the bot created for testing, albeit with the catch that it will submit your package to Factory.
Yes, and that's my concern -- the build and integration test isn't done before submission unlike the current workflow with OBS. I believe (or hope) that FACTORY submission will check more strictly about the build status of the project created by bot, but the PR to devel project needs the testing at first, too.
I am honestly not sure how many packages actually have some integration testing setup in their devel projects, hence we choose the "easy way out" and decided to bypass this step. But as mentioned in another email, it wouldn't be too hard to let the bot create a test project for a draft pull request and *not* submit it. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On Wed, 19 Jul 2023 15:26:50 +0200, Dan Čermák wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:08:11 +0200, Dan Čermák wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 14:14:44 +0200, Dan Čermák wrote:
Hi Takashi,
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 11:28:12 +0200, Dan Čermák via openSUSE Factory wrote: > > Dear packagers for openSUSE Tumbleweed, > > we have been working on a prototype that allows you to maintain your > packages in git (similarly to Fedora's dist git) on src.opensuse.org > instead of on OBS. Contributions to the package are then handled via > pull requests on src.opensuse.org which get automatically forwarded as > submitrequests on OBS. > > This is currently just a prototype and we are looking for testers and > general feedback. So if you want to participate as a maintainer, please > check the full guide here: > https://opensuse.github.io/scm-staging/user_guide.html > > tl;dr; you'll have to convert the develpackage to use `<scmsync>` from > src.opensuse.org/pool and everything else should "just work".
This looks awesome, I'd love to give it a try.
But, maybe because I have no clear "big picture" yet, I don't see how it fits with the actual package development work. Usually, a package is branched to home:$user:branches:$develproj, patched there, built, tested, then finally submitted to $develproj (which goes eventually to FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows:
- you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request
The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
Hope this answers your questions,
Hmm. Before doing a PR, you'll need to build and test a package. And, that's done in OBS home:*:branches:* in the past. That is, the branched develproject itself was a test bench. So, what's not clear to me is, in the flow above:
1. you fork the package in src.opensuse.org/pool/$pkg 2a. you implement your changes 2b. and submit a pull request against the repository in pool/$pkg
between 2a and 2b, you need the package build and test. But how would it be done?
Local builds should still be possible, so you can build and test it locally.
But I don't build the whole architectures and repos locally. I suppose one can still commit to a branched project, build/test it, then it's synced to git src.o.o and git-PR? Is it the expected way?
No, as I wrote in the FAQ, branching a package on OBS will no longer work once you use scmsync.
This is a design limitation in OBS: a package relying on scmsync is synchronized just one way git -> OBS. OBS pulls the git repository and imports it into its own version control. Hence if you would create a submitrequest on such a package, you couldn't accept it anyway as that would yield inconsistent states between OBS and git. The only ways out of this issue are either to forbid submitrequests or to teach OBS to talk git natively.
Well, what I meant is not to submit from the branched OBS project, but just allow to build and test from the branched project, while keeping the source contents in git, and the submission is done over git. So it's more or less as same as what you suggested, but the build/test isn't tied with the git-PR, and the (branched) project creation is still a manual work.
Otherwise, you can also create a pull request and use the project that the bot created for testing, albeit with the catch that it will submit your package to Factory.
Yes, and that's my concern -- the build and integration test isn't done before submission unlike the current workflow with OBS. I believe (or hope) that FACTORY submission will check more strictly about the build status of the project created by bot, but the PR to devel project needs the testing at first, too.
I am honestly not sure how many packages actually have some integration testing setup in their devel projects, hence we choose the "easy way out" and decided to bypass this step. But as mentioned in another email, it wouldn't be too hard to let the bot create a test project for a draft pull request and *not* submit it.
Yes, it sounds like a required step in many cases. For packages that have no CI tests, it'd be almost mandatory. And that matches with the majority of leaf packages, I guess. A slight itch feeling is, though, that the testing phase is basically a step before the pull request phase. So, we want to have a test bench OBS project rather *during* the development. If it can be triggered from src.o.o side independently from the git-PR action, that'll be helpful. thanks, Takashi
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:26:50 +0200, Dan Čermák wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 15:08:11 +0200, Dan Čermák wrote:
Takashi Iwai <tiwai@suse.de> writes:
On Wed, 19 Jul 2023 14:14:44 +0200, Dan Čermák wrote:
Hi Takashi,
Takashi Iwai <tiwai@suse.de> writes:
> On Wed, 19 Jul 2023 11:28:12 +0200, > Dan Čermák via openSUSE Factory wrote: >> >> Dear packagers for openSUSE Tumbleweed, >> >> we have been working on a prototype that allows you to maintain your >> packages in git (similarly to Fedora's dist git) on src.opensuse.org >> instead of on OBS. Contributions to the package are then handled via >> pull requests on src.opensuse.org which get automatically forwarded as >> submitrequests on OBS. >> >> This is currently just a prototype and we are looking for testers and >> general feedback. So if you want to participate as a maintainer, please >> check the full guide here: >> https://opensuse.github.io/scm-staging/user_guide.html >> >> tl;dr; you'll have to convert the develpackage to use `<scmsync>` from >> src.opensuse.org/pool and everything else should "just work". > > This looks awesome, I'd love to give it a try. > > But, maybe because I have no clear "big picture" yet, I don't see how > it fits with the actual package development work. Usually, a package > is branched to home:$user:branches:$develproj, patched there, built, > tested, then finally submitted to $develproj (which goes eventually to > FACTORY). With the git workflow, how does it change?
We are experimenting with a workflow that is less devel-project-centric. The currently anticipated workflow to contribute to $pkg looks as follows:
- you fork the package in src.opensuse.org/pool/$pkg - you implement your changes and submit a pull request against the repository in pool/$pkg - a bot will create a submission from a new project on OBS to openSUSE:Factory directly with your modifications - if the SR to Factory is accepted, then the bot will merge the pull request
The develproject is still there, it builds whatever is currently in src.opensuse.org/pool/$pkg (that should be however more or less exactly what is in Factory).
Hope this answers your questions,
Hmm. Before doing a PR, you'll need to build and test a package. And, that's done in OBS home:*:branches:* in the past. That is, the branched develproject itself was a test bench. So, what's not clear to me is, in the flow above:
1. you fork the package in src.opensuse.org/pool/$pkg 2a. you implement your changes 2b. and submit a pull request against the repository in pool/$pkg
between 2a and 2b, you need the package build and test. But how would it be done?
Local builds should still be possible, so you can build and test it locally.
But I don't build the whole architectures and repos locally. I suppose one can still commit to a branched project, build/test it, then it's synced to git src.o.o and git-PR? Is it the expected way?
No, as I wrote in the FAQ, branching a package on OBS will no longer work once you use scmsync.
This is a design limitation in OBS: a package relying on scmsync is synchronized just one way git -> OBS. OBS pulls the git repository and imports it into its own version control. Hence if you would create a submitrequest on such a package, you couldn't accept it anyway as that would yield inconsistent states between OBS and git. The only ways out of this issue are either to forbid submitrequests or to teach OBS to talk git natively.
Well, what I meant is not to submit from the branched OBS project, but just allow to build and test from the branched project, while keeping the source contents in git, and the submission is done over git. So it's more or less as same as what you suggested, but the build/test isn't tied with the git-PR, and the (branched) project creation is still a manual work.
I don't disagree with you, the problem here is mostly how to trigger builds and report back to the user in a useful manner. We could certainly make the bot listen to repositories getting forked, setup these test projects for each fork+branch and report build results back as a commit status. Would that be desirable for you as a user? Would it be very well discoverable (sadly the build status is just a yellow/green/red dot next to the commit sha)?
Otherwise, you can also create a pull request and use the project that the bot created for testing, albeit with the catch that it will submit your package to Factory.
Yes, and that's my concern -- the build and integration test isn't done before submission unlike the current workflow with OBS. I believe (or hope) that FACTORY submission will check more strictly about the build status of the project created by bot, but the PR to devel project needs the testing at first, too.
I am honestly not sure how many packages actually have some integration testing setup in their devel projects, hence we choose the "easy way out" and decided to bypass this step. But as mentioned in another email, it wouldn't be too hard to let the bot create a test project for a draft pull request and *not* submit it.
Yes, it sounds like a required step in many cases. For packages that have no CI tests, it'd be almost mandatory. And that matches with the majority of leaf packages, I guess.
A slight itch feeling is, though, that the testing phase is basically a step before the pull request phase. So, we want to have a test bench OBS project rather *during* the development. If it can be triggered from src.o.o side independently from the git-PR action, that'll be helpful.
I must confess that I don't have a great idea how, except to automatically setup such a testbench for forks. I am very much open to other suggestions though! Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On Wed, Jul 19, 2023 at 04:31:13PM +0200, Dan Čermák via openSUSE Factory wrote:
I don't disagree with you, the problem here is mostly how to trigger builds and report back to the user in a useful manner. We could certainly make the bot listen to repositories getting forked, setup these test projects for each fork+branch and report build results back as a commit status.
Would that be desirable for you as a user? Would it be very well discoverable (sadly the build status is just a yellow/green/red dot next to the commit sha)? Yes, this sounds very desirable. Ideally the bot would create a test project on OBS, build the forked Git repo head (at least) and make the results (OK/KO, built RPMs and rpmlint / build log) available. Other than the green/yellow/red dot, the bot could add links the build artifacts e.g. in a comment on a commit.
Filippo -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
Hi Filippo, Filippo Bonazzi <fbonazzi@suse.de> writes:
On Wed, Jul 19, 2023 at 04:31:13PM +0200, Dan Čermák via openSUSE Factory wrote:
I don't disagree with you, the problem here is mostly how to trigger builds and report back to the user in a useful manner. We could certainly make the bot listen to repositories getting forked, setup these test projects for each fork+branch and report build results back as a commit status.
Would that be desirable for you as a user? Would it be very well discoverable (sadly the build status is just a yellow/green/red dot next to the commit sha)?
Yes, this sounds very desirable. Ideally the bot would create a test project on OBS, build the forked Git repo head (at least) and make the results (OK/KO, built RPMs and rpmlint / build log) available. Other than the green/yellow/red dot, the bot could add links the build artifacts e.g. in a comment on a commit.
Adding a comment on a commit sounds doable, albeit it would have to get continuously updated. If you have concrete ideas how this could look like in practice to be useful for *you*, would you please open an issue or create a discussion on https://github.com/openSUSE/scm-staging? I would prefer not to implement something totally against user's wishes. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Yes, this sounds very desirable. Ideally the bot would create a test project on OBS, build the forked Git repo head (at least) and make the results (OK/KO, built RPMs and rpmlint / build log) available. Other than the green/yellow/red dot, the bot could add links the build artifacts e.g. in a comment on a commit.
you can have that by using the already existing git scm workflow, no need to reinvent the wheels in the scm-staging bot.
Adding a comment on a commit sounds doable, albeit it would have to get continuously updated.
There is a status api where you can attach a testing status (build status) to each git commit. please don't do it as comments, this is imho quite messy and distracts from human review comments (it is sort of bearable in BCI-dockerfile-generator because it rarely gets review comments). Greetings, Dirk
On Thu, Jul 20, 2023 at 01:57:39PM +0200, Dirk Müller wrote:
Yes, this sounds very desirable. Ideally the bot would create a test project on OBS, build the forked Git repo head (at least) and make the results (OK/KO, built RPMs and rpmlint / build log) available. Other than the green/yellow/red dot, the bot could add links the build artifacts e.g. in a comment on a commit.
you can have that by using the already existing git scm workflow, no need to reinvent the wheels in the scm-staging bot. What I'm saying is, I feel like this functionality should be available by default in a new Git-based workflow, as it would be the only way to have access to build results when working outside of OBS. Having to set up Git<->OBS integration manually for every fork of every repo I would ever interact with on src.opensuse.org sounds like a lot of work.
-- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
Hi Filippo and Dirk, Filippo Bonazzi <fbonazzi@suse.de> writes:
On Thu, Jul 20, 2023 at 01:57:39PM +0200, Dirk Müller wrote:
Yes, this sounds very desirable. Ideally the bot would create a test project on OBS, build the forked Git repo head (at least) and make the results (OK/KO, built RPMs and rpmlint / build log) available. Other than the green/yellow/red dot, the bot could add links the build artifacts e.g. in a comment on a commit.
you can have that by using the already existing git scm workflow, no need to reinvent the wheels in the scm-staging bot. What I'm saying is, I feel like this functionality should be available by default in a new Git-based workflow, as it would be the only way to have access to build results when working outside of OBS. Having to set up Git<->OBS integration manually for every fork of every repo I would ever interact with on src.opensuse.org sounds like a lot of work.
I agree with Filippo here, setting up the integration yourself for every fork is pointless busywork and makes the git based workflow *worse* than the existing workflow on OBS. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
What I'm saying is, I feel like this functionality should be available by default in a new Git-based workflow, as it would be the only way to have access to build results when working outside of OBS. Having to set up Git<->OBS integration manually for every fork of every repo I would ever interact with on src.opensuse.org sounds like a lot of work. I agree with Filippo here, setting up the integration yourself for every fork is pointless busywork and makes the git based workflow *worse* than the existing workflow on OBS.
I'm not suggesting that it needs to be manually set up. Every pool package needs to bring its testing qualities (some might be fine with a build check, some might want to have more etc). and I agree that branching those gits should also bring that to the git branches. My current limited understanding of how the git-scm workflows work is that you already have that functionality. I'll set it up as an example to learn more about that. Greetings, Dirk
On Donnerstag, 20. Juli 2023, 14:20:37 CEST Dan Čermák via openSUSE Factory wrote:
Hi Filippo and Dirk,
Filippo Bonazzi <fbonazzi@suse.de> writes:
On Thu, Jul 20, 2023 at 01:57:39PM +0200, Dirk Müller wrote:
Yes, this sounds very desirable. Ideally the bot would create a test project on OBS, build the forked Git repo head (at least) and make the results (OK/KO, built RPMs and rpmlint / build log) available. Other than the green/yellow/red dot, the bot could add links the build artifacts e.g. in a comment on a commit.
you can have that by using the already existing git scm workflow, no need to reinvent the wheels in the scm-staging bot. What I'm saying is, I feel like this functionality should be available by default in a new Git-based workflow, as it would be the only way to have access to build results when working outside of OBS. Having to set up Git<->OBS integration manually for every fork of every repo I would ever interact with on src.opensuse.org sounds like a lot of work.
I agree with Filippo here, setting up the integration yourself for every fork is pointless busywork and makes the git based workflow *worse* than the existing workflow on OBS.
Absolutely, but we have to keep in mind that we want to support scenarios where a package git is build in multiple projects, offering multiple flavors based on the config there (eg. switching on/off certain functionality). So a simple branch mechanism as we had it so far would not be sufficient. The other freedom, which we want to achieve is that you can easily do these test builds in non-OBS infrastructure (eg. because you have your QA systems there as well). For the ALP project we have already a config which allows to run "pbuild" in any place (however, also a lot is missing there as well). Neverthless we should also aim to support this kind build setups where you can build a set of packages reproducible as in OBS IMHO (also for Factory, for ALP we definitive will). The question for me is how to allow users to create these kinds of setups easily. Doesn't have to be bound to OBS, might be created with some dedicated small tooling though. On the other side, we should try to keep the setups for our users centralized where one can get newer software stacks of Factory also for older or foreign distros IMHO. I personally consider these as the main benefit for users and also for factory developers as our devel projects give benifits to both parties. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Hi Takashi,
Well, what I meant is not to submit from the branched OBS project, but just allow to build and test from the branched project, while keeping the source contents in git, and the submission is done over git. So it's more or less as same as what you suggested, but the build/test isn't tied with the git-PR, and the (branched) project creation is still a manual work.
I'm not sure I follow, but isn't that the matter of adding an extra remote "testing" that you git push to which is setup as scmsync in a staging environment? then you have server side builds + testing without having to go through the SR workflow. you trigger the latter when everything is ready.
Hi Dirk, Dirk Müller <dirk@dmllr.de> writes:
Hi Takashi,
Well, what I meant is not to submit from the branched OBS project, but just allow to build and test from the branched project, while keeping the source contents in git, and the submission is done over git. So it's more or less as same as what you suggested, but the build/test isn't tied with the git-PR, and the (branched) project creation is still a manual work.
I'm not sure I follow, but isn't that the matter of adding an extra remote "testing" that you git push to which is setup as scmsync in a staging environment?
That is certainly possible, but it is at the moment more work that the existing workflow. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am Mittwoch, 19. Juli 2023, 15:18:03 CEST schrieb Takashi Iwai:
But I don't build the whole architectures and repos locally. I suppose one can still commit to a branched project, build/test it, then it's synced to git src.o.o and git-PR? Is it the expected way?
Otherwise, you can also create a pull request and use the project that the bot created for testing, albeit with the catch that it will submit your package to Factory.
Yes, and that's my concern -- the build and integration test isn't done before submission unlike the current workflow with OBS. I believe (or hope) that FACTORY submission will check more strictly about the build status of the project created by bot, but the PR to devel project needs the testing at first, too.
That packages were not tested before uploading and thus do not build is already increasing. I assume that will be much worse. Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 19. Juli 2023, 15:18:03 CEST schrieb Takashi Iwai:
But I don't build the whole architectures and repos locally. I suppose one can still commit to a branched project, build/test it, then it's synced to git src.o.o and git-PR? Is it the expected way?
Otherwise, you can also create a pull request and use the project that the bot created for testing, albeit with the catch that it will submit your package to Factory.
Yes, and that's my concern -- the build and integration test isn't done before submission unlike the current workflow with OBS. I believe (or hope) that FACTORY submission will check more strictly about the build status of the project created by bot, but the PR to devel project needs the testing at first, too.
That packages were not tested before uploading and thus do not build is already increasing. I assume that will be much worse.
Packages that do not build will be auto-declined by factory-auto, thus I don't see this as an immediate issue. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On Wed, 2023-07-19 at 16:36 +0200, Dan Čermák via openSUSE Factory wrote:
That packages were not tested before uploading and thus do not build is already increasing. I assume that will be much worse.
Packages that do not build will be auto-declined by factory-auto, thus I don't see this as an immediate issue.
that's news to me - and never happened so far and I have not seen any code implying this. factory-auto does source validation only, no build result validation. Stuff that does not build ends up being blocked in a staging project as it is now. cheers, Dominique
Dominique Leuenberger <dimstar@opensuse.org> writes:
On Wed, 2023-07-19 at 16:36 +0200, Dan Čermák via openSUSE Factory wrote:
That packages were not tested before uploading and thus do not build is already increasing. I assume that will be much worse.
Packages that do not build will be auto-declined by factory-auto, thus I don't see this as an immediate issue.
that's news to me - and never happened so far and I have not seen any code implying this.
factory-auto does source validation only, no build result validation.
Stuff that does not build ends up being blocked in a staging project as it is now.
Whoops, my mistake. Sorry. But the end result is the same: not building submissions will not land. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am 19.07.23 um 15:18 schrieb Takashi Iwai:
But I don't build the whole architectures and repos locally.
That would be my biggest concern. I can build x86 locally (though for LLVM I'd rather not, it takes many hours on my machine), but I can't build ARM, PowerPC, SystemZ and RISC-V. Devel projects often have a lot more builds than the submit to Factory. Aaron
On 19.07.23 at 11:28 Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html Awesome! Thanks for the (lot of) fantastic work in getting this working.
I'll wait until the next update for trivy pops up and will try to submit an update this way. Out of interest: Is there a way to find out, which packages are already "converted"? Can I see this in the OBS UI somehow? Without looking at each package separately? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Johannes Kastl <kastl@b1-systems.de> writes:
On 19.07.23 at 11:28 Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html Awesome! Thanks for the (lot of) fantastic work in getting this working.
I'll wait until the next update for trivy pops up and will try to submit an update this way.
Out of interest: Is there a way to find out, which packages are already "converted"? Can I see this in the OBS UI somehow? Without looking at each package separately?
I am afraid not, at least I don't know a straight forward way. I thought that you might be able to use the GET /search/package route of the API[1] and use an XPath to search for the presence of the scmsync entry, but it looks like that is not a supported XPath. Cheers, Dan Footnotes: [1] https://api.opensuse.org/apidocs/index#/Search/get_search_package -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On Wed, 2023-07-19 at 11:28 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
FAQ:
- Where can I report issues or provide feedback? https://github.com/openSUSE/scm-staging/issues (for bugs) or https://github.com/openSUSE/scm-staging/discussions (for general feedback)
- Is this how the future of packaging in openSUSE is going to look like? Maybe, maybe not. This is currently just a test drive and its outcome will influence the way forward.
- Will submitrequests to my develpackage still work? Sadly no, branching a git maintained package on OBS does not work. Please indicate in the description of your package that users should contribute on src.opensuse.org instead.
- Which tools do I need? Just git, git-lfs and osc (at least version 1.2.0 is recommended for service runs to work)
Looking forward to your feedback!
Dan
I have a few questions as I try to give this a go :) 1. what's the intention behind the https://src.opensuse.org/rpm area? I see a package in /pool ("Updated 2 weeks ago") but it's less up-to-date than the /rpm fork ("Updated 20 hours ago"). I see most any package I maintain that's been updated in the not-too-distant-past like this. 2. Under "Contributor Guide" it says "1. Install the `git-scm-bridge`" - is this supposed to to `obs-scm-bridge`? Seems so, but maybe I just don't have a repo which offers `git-scm-bridge` up. 3. Also under "Contributor Guide", for "4. Add the fork ..." - the code block shows `git remote add fork gitea@src.opensuse.org/$username/$pkg_name` but that doesn't work when you later do `git push fork` since I had to change it to: `gitea@src.opensuse.org:$username/$pkg_name`. I _think_ that's the general convention when SSH in involved, but I'm not a git expert. -- ~ Scott Bradnick | Windows Subsystem for Linux (WSL) Developer |- Tumbleweed: |-- Beelink SER6 Pro [AMD Rembrandt [Radeon 680M]] (x86_64) |-- Dell Precision 5540 [NVIDIA Quadro T1000] (x86_64) |-- IceWhale ZimaBoard 832 [Intel HD Graphics 500] (x86_64) |-- WinBook TW100 (x86_64) |- MicroOS: |-- O-DROID H2+ [UHD Graphics 600] (x86_64) https://keys.openpgp.org/ :: DBC5AA9A2D2BAEBC
Hi Scott, Am Mi., 19. Juli 2023 um 19:29 Uhr schrieb Scott Bradnick via openSUSE Factory <factory@lists.opensuse.org>:
I have a few questions as I try to give this a go :)
1. what's the intention behind the https://src.opensuse.org/rpm area?
it is currently a bot that automatically converts sources as they are in the currently defined development projects and factory into a git repository. you can pull from that the changes into your submission into pool so that you're not losing any history.
package in /pool ("Updated 2 weeks ago") but it's less up-to-date than the /rpm fork ("Updated 20 hours ago"). I see most any package I maintain that's been updated in the not-too-distant-past like this.
Yes, I created the pool/ setup two weeks ago when we originally thought this announcement would go out. I can sync again any package that you're interested in.
2. Under "Contributor Guide" it says "1. Install the `git-scm-bridge`" - is this supposed to to `obs-scm-bridge`? Seems so, but maybe I just don't have a repo which offers `git-scm-bridge` up.
Yes, obs-scm-bridge. will fix this typo.
3. Also under "Contributor Guide", for "4. Add the fork ..." - the code block shows `git remote add fork gitea@src.opensuse.org/$username/$pkg_name` but that doesn't work when you later do `git push fork` since I had to change it to: `gitea@src.opensuse.org:$username/$pkg_name`. I _think_ that's the general convention when SSH in involved, but I'm not a git expert.
you're correct the slash is wrong. PRs accepted :) Greetings, Dirk
Hi Scott, Scott Bradnick via openSUSE Factory <factory@lists.opensuse.org> writes:
On Wed, 2023-07-19 at 11:28 +0200, Dan Čermák via openSUSE Factory wrote:
Dear packagers for openSUSE Tumbleweed,
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
FAQ:
- Where can I report issues or provide feedback? https://github.com/openSUSE/scm-staging/issues (for bugs) or https://github.com/openSUSE/scm-staging/discussions (for general feedback)
- Is this how the future of packaging in openSUSE is going to look like? Maybe, maybe not. This is currently just a test drive and its outcome will influence the way forward.
- Will submitrequests to my develpackage still work? Sadly no, branching a git maintained package on OBS does not work. Please indicate in the description of your package that users should contribute on src.opensuse.org instead.
- Which tools do I need? Just git, git-lfs and osc (at least version 1.2.0 is recommended for service runs to work)
Looking forward to your feedback!
Dan
I have a few questions as I try to give this a go :)
1. what's the intention behind the https://src.opensuse.org/rpm area? I see a package in /pool ("Updated 2 weeks ago") but it's less up-to-date than the /rpm fork ("Updated 20 hours ago"). I see most any package I maintain that's been updated in the not-too-distant-past like this.
2. Under "Contributor Guide" it says "1. Install the `git-scm-bridge`" - is this supposed to to `obs-scm-bridge`? Seems so, but maybe I just don't have a repo which offers `git-scm-bridge` up.
3. Also under "Contributor Guide", for "4. Add the fork ..." - the code block shows `git remote add fork gitea@src.opensuse.org/$username/$pkg_name` but that doesn't work when you later do `git push fork` since I had to change it to: `gitea@src.opensuse.org:$username/$pkg_name`. I _think_ that's the general convention when SSH in involved, but I'm not a git expert.
2 and 3 have been fixed, thanks for spotting that! Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hello! On Wed, 2023-07-19 at 11:28 +0200, Dan Čermák via openSUSE Factory wrote:
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
Looks like signing in has been disabled for the time being, hasn't it? I tried logging in with my IDP account but I got the error that creating new accounts has been disabled and I have to talk to an administrator. Adrian
Adrian Glaubitz <adrian.glaubitz@suse.com> writes:
Hello!
On Wed, 2023-07-19 at 11:28 +0200, Dan Čermák via openSUSE Factory wrote:
This is currently just a prototype and we are looking for testers and general feedback. So if you want to participate as a maintainer, please check the full guide here: https://opensuse.github.io/scm-staging/user_guide.html
tl;dr; you'll have to convert the develpackage to use `<scmsync>` from src.opensuse.org/pool and everything else should "just work".
Looks like signing in has been disabled for the time being, hasn't it?
I tried logging in with my IDP account but I got the error that creating new accounts has been disabled and I have to talk to an administrator.
Yes, Dirk had to disable account creation as spammers found src.o.o 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 Fri, 2023-10-06 at 10:51 +0200, Dan Čermák wrote:
Looks like signing in has been disabled for the time being, hasn't it?
I tried logging in with my IDP account but I got the error that creating new accounts has been disabled and I have to talk to an administrator.
Yes, Dirk had to disable account creation as spammers found src.o.o
OK. Could you create an account for me please? Adrian
Hi Dan! On Wed, 2023-07-19 at 11:28 +0200, Dan Čermák via openSUSE Factory wrote:
we have been working on a prototype that allows you to maintain your packages in git (similarly to Fedora's dist git) on src.opensuse.org instead of on OBS. Contributions to the package are then handled via pull requests on src.opensuse.org which get automatically forwarded as submitrequests on OBS.
I wanted to migrate some packages of the Public Cloud Team to git on src.opensuse.org and tried adding both my public SSH key as well as my public GPG key. While the GPG key was accepted without any issues, my SSH was rejected with the following error message that indicates the key is too short: "Cannot verify your SSH key: key length is not enough: got 2048, needs 3071" After a quick web search, it turns out that this is related to the minimum key length check being enabled: "MINIMUM_KEY_SIZE_CHECK = true" Is this intentional? If yes, what is the recommended way to generate an SSH key (although I would like to avoid having to create new keys)? Thanks, Adrian
Hi Adrian, Am Fr., 8. Dez. 2023 um 12:37 Uhr schrieb Adrian Glaubitz via openSUSE Factory <factory@lists.opensuse.org>:
While the GPG key was accepted without any issues, my SSH was rejected with the following error message that indicates the key is too short:
"Cannot verify your SSH key: key length is not enough: got 2048, needs 3071"
After a quick web search, it turns out that this is related to the minimum key length check being enabled:
"MINIMUM_KEY_SIZE_CHECK = true"
Is this intentional?
It is the default setting of gitea 1.21, which we're using on the openSUSE side. No explicit configuration has been done from our side so far. you can read the minimums here: https://docs.gitea.com/next/administration/config-cheat-sheet#ssh-minimum-ke... Please note that all current openssh versions generate ed25519 keys by default which are shorter, more secure, much faster and would be accepted without any issue. Also see https://www.keylength.com/en/compare/ which basically says that *new* RSA 2048 should not be used after 2020 anymore. We have 2023. Greetings, Dirk
Hello, On Fri, 2023-12-08 at 14:17 +0100, Dirk Müller wrote:
Is this intentional?
It is the default setting of gitea 1.21, which we're using on the openSUSE side. No explicit configuration has been done from our side so far.
OK.
you can read the minimums here: https://docs.gitea.com/next/administration/config-cheat-sheet#ssh-minimum-ke...
Please note that all current openssh versions generate ed25519 keys by default which are shorter, more secure, much faster and would be accepted without any issue.
I'm aware that newer keys are more secure, but that's not the point. New keys means I have to start replacing keys on various hosts.
Also see https://www.keylength.com/en/compare/ which basically says that *new* RSA 2048 should not be used after 2020 anymore. We have 2023.
That's not really clear from this website as it refers to different papers which make different recommendations. If a key type is considered insecure, it would have been completely blocked by OpenSSH as it has happened for DSA keys. But up to now, RSA2048 is still a valid and enabled key type which is why it's annoying when random projects decide they know better. *sigh* Adrian
Hi Adrian, Am Fr., 8. Dez. 2023 um 15:27 Uhr schrieb John Paul Adrian Glaubitz <adrian.glaubitz@suse.com>:
But up to now, RSA2048 is still a valid and enabled key type which is why it's annoying when random projects decide they know better.
well, openssh switched the default for the same reason. so it's not just 'random projects'. plus integrity of a source revision control is kinda relevant as well. If you want, I can check with the suse security team and if they agree we can allow RSA 2048 as a temporary solution. But to be honest with you, I'm a strong advisor for security where it doesn't hurt, and this is imho one case where there are no downsides. Greetings, Dirk
participants (23)
-
Aaron Puchert -
Adrian Glaubitz -
Adrian Schröter -
Dan Čermák -
Dirk Müller -
Dirk Müller -
Dominik Gedon -
Dominique Leuenberger -
Eric Schirra -
Eyad Issa -
eyadlorenzo＠gmail.com
-
Filippo Bonazzi -
Jan Engelhardt -
Jiri Slaby -
Johannes Kastl -
John Paul Adrian Glaubitz
-
Matěj Cepl -
Neal Gompa -
Robert Schweikert -
Scott Bradnick -
Simon Lees -
Takashi Iwai -
Vojtěch Zeisek