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/

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/

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 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!

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/

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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)

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