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