Simon Lees <sflees@suse.de> writes:
On 4/20/23 16:31, Dan Čermák wrote:
Hi Richard,
thank you for this detailed write-up!
(more inline below)
Richard Brown <rbrown@suse.de> writes:
*snip*
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
Would you know where the primary development will take place? OBS or IBS?
If it is moved to IBS, then that will make community contributions quite challenging, as they already are with Leap at the moment. Would it be an option that development happens on OBS and the sources are mirrored/copied/submitted to IBS? That's our current workflow for SLE-BCI and I'd say it works reasonably well, albeit I am not sure if it would scale.
My understanding of Common Critera Cert is that all submissions need to be reviewed twice internally, ie by the package maintainer and the SUSE review team. So I think probably the best you could do is add some mechanism where by a community member could somehow create a SR that gets forwarded into IBS so that the maintainer and other relevant people could review it there before inclusion. Which would likely be significant changes in IBS/OBS. But maybe I got those requirements wrong its been a long time since I discussed them with people.
That's how it's supposed to work currently with submissions to Leap: your SR gets mirrored internally on IBS. Unfortunately that means that if the submission needs modifications, then things get very complicated and usually involve manual steps (someone from SUSE forwarding the feedback to the community contributor, starting a lengthy back-and-forth). I'd very much prefer if we do not repeat this process for ALP at all.
Given that we are also looking at the git based packaging workflow it might make more sense to just wind up with a working review system for the community there.
Git will not fundamentally change that community contributors don't have access to the SUSE internal infrastructure. What git might help with is commits having hashes and being signed, which would allow for an automated cherry-pick/clone. But it's still not a trivial thing to solve. 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