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