Looking for packagers interested in maintaining opensuse tumbleweed packages in git
Hi, for a while src.opensuse.org has been serving git-converted history of openSUSE Tumbleweed packages. We recently switched that to SHA256 which is the git format chosen for package maintenance in git going forward. We are aware of many unsolved issues but are afraid to miss some others. Therefore I'd like to invite you to opt in maintaining some of your existing packages in git and help us find and resolve issues in the tooling (osc, and maybe anything else you're using). The way on how to do that is documented in https://opensuse.github.io/scm-staging/user_guide.html#contributor-guide This is a bot that forwards PRs from one place to SRs in the other place. This is a migration helper, it's not supposed to stay that way, so don't focus on this part too much. the interesting part is learning what else you need over today in making the "local packaging experience as good or better" with package sources stored in git. feel free to report the issues or chat about them on https://github.com/openSUSE/openSUSE-git/discussions Looking forward to your feedback and issues raised. Thanks, Dirk -- SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nuernberg Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Just curious: what is the rationale for offering that alternate git workflow for maintaining packages vs OBS ? Who would use that and for which reason ? On 6/26/24 2:29 PM, Dirk Müller via openSUSE Factory wrote:
Hi,
for a while src.opensuse.org has been serving git-converted history of openSUSE Tumbleweed packages. We recently switched that to SHA256 which is the git format chosen for package maintenance in git going forward. We are aware of many unsolved issues but are afraid to miss some others. Therefore I'd like to invite you to opt in maintaining some of your existing packages in git and help us find and resolve issues in the tooling (osc, and maybe anything else you're using).
The way on how to do that is documented in https://opensuse.github.io/scm-staging/user_guide.html#contributor-guide
This is a bot that forwards PRs from one place to SRs in the other place. This is a migration helper, it's not supposed to stay that way, so don't focus on this part too much. the interesting part is learning what else you need over today in making the "local packaging experience as good or better" with package sources stored in git.
feel free to report the issues or chat about them on https://github.com/openSUSE/openSUSE-git/discussions
Looking forward to your feedback and issues raised.
Thanks, Dirk
Hi Michael, Am Mi., 26. Juni 2024 um 14:40 Uhr schrieb Michael Pujos <pujos.michael@gmail.com>:
Just curious: what is the rationale for offering that alternate git workflow for maintaining packages vs OBS ? Who would use that and for which reason ?
There's been two hypotheses around that: * It is easier to get drive-by contributions as the general familiarity of git + PR workflow is higher than having to sign up for a separate account on a separate web site having to install a separate tool to submit a change (adding a patch, updating a version) * It eases the maintenance of a package in multiple code streams because branches are a first class feature of git, while it is an afterthought in the custom subversion-like source control system of the Open Build Service We can not really validate point two at the moment as there is only one distribution enabled with git so far. Part of this exercise is to find out whether any of those hypotheses are holding up. Greetings, Dirk
On Thursday 2024-06-27 08:52, Dirk Müller via openSUSE Factory wrote:
Am Mi., 26. Juni 2024 um 14:40 Uhr schrieb Michael Pujos <pujos.michael@gmail.com>:
Just curious: what is the rationale for offering that alternate git workflow for maintaining packages vs OBS ? Who would use that and for which reason ?
There's been two hypotheses around that:
* It is easier to get drive-by contributions as the general familiarity of git + PR workflow is higher than having to sign up for a separate account on a separate web site having to install a separate tool to submit a change (adding a patch, updating a version) * It eases the maintenance of a package in multiple code streams because branches are a first class feature of git, while it is an afterthought in the custom subversion-like source control system of the Open Build Service
and * Downloading history is simply faster because you don't have the latency of one HTTP request multiplied by number of files multiplied by number of revisions you want to have.
Hello Dirk, Am Mittwoch, 26. Juni 2024, 14:29:58 MESZ schrieb Dirk Müller via openSUSE Factory: ....
feel free to report the issues or chat about them on https://github.com/openSUSE/openSUSE-git/discussions
Looking forward to your feedback and issues raised.
While I cant comment on the technical side, I'm more concerned about the freedom side of github. github is owned by M$, with all negative consequences we can face from this. We should rather take this as an opportunity to move to more freedom-oriented hoster, like gitlab or codeberg. My 2c on this.... Axel
On 26/06/2024 14.46, Axel Braun wrote:
We should rather take this as an opportunity to move to more freedom-oriented hoster, like gitlab or codeberg.
Or we could self-host it on src.opensuse.org (Gitea) or code.opensuse.org (pagure) . Luckily the decentralized nature of git means that we can have the same content in multiple places. The harder bits would be the issue-tracking and pull-requests plus discussions here. Also there are network-effects to consider. Most developers already have a GitHub-account, but maybe not on the other hosting platforms. This increases the barrier for the first contribution. Ciao Bernhard M.
On Wed, Jun 26, 2024 at 03:34:26PM +0200, Bernhard M. Wiedemann via openSUSE Factory wrote:
On 26/06/2024 14.46, Axel Braun wrote:
We should rather take this as an opportunity to move to more freedom-oriented hoster, like gitlab or codeberg.
Or we could self-host it on src.opensuse.org (Gitea) or code.opensuse.org (pagure) . Luckily the decentralized nature of git means that we can have the same content in multiple places. The harder bits would be the issue-tracking and pull-requests plus discussions here.
Also there are network-effects to consider. Most developers already have a GitHub-account, but maybe not on the other hosting platforms. This increases the barrier for the first contribution.
To be clear, the git server we will use is gitea on src.opensuse.org, our hosted gitea instance. Only the discussion of this topic is supposed to be in github. Ciao, Marcus
Am Mittwoch, 26. Juni 2024, 15:45:17 MESZ schrieb Marcus Meissner:
To be clear, the git server we will use is gitea on src.opensuse.org, our hosted gitea instance.
Only the discussion of this topic is supposed to be in github.
Thanks for the clarification, Marcus, this is really positive! See you at oSC Axel
Am Mittwoch, 26. Juni 2024, 15:45:17 MESZ schrieb Marcus Meissner:
To be clear, the git server we will use is gitea on src.opensuse.org, our hosted gitea instance.
Only the discussion of this topic is supposed to be in github.
Actually, what’s so much better about GitHub discussions over git@lists.opensuse.org (or something like that)? Why do we have to use GitHub? Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A woman without a man is like a fish without a bicycle. Therefore, a man without a woman is like a bicycle without a fish.
This is amazing and I really look forward to try this out for the few packages I maintain and help maintaining. Thanks for the heads up! Alessio
Il giorno 26 giu 2024, alle ore 14:30, Dirk Müller via openSUSE Factory <factory@lists.opensuse.org> ha scritto:
Hi,
for a while src.opensuse.org has been serving git-converted history of openSUSE Tumbleweed packages. We recently switched that to SHA256 which is the git format chosen for package maintenance in git going forward. We are aware of many unsolved issues but are afraid to miss some others. Therefore I'd like to invite you to opt in maintaining some of your existing packages in git and help us find and resolve issues in the tooling (osc, and maybe anything else you're using).
The way on how to do that is documented in https://opensuse.github.io/scm-staging/user_guide.html#contributor-guide
This is a bot that forwards PRs from one place to SRs in the other place. This is a migration helper, it's not supposed to stay that way, so don't focus on this part too much. the interesting part is learning what else you need over today in making the "local packaging experience as good or better" with package sources stored in git.
feel free to report the issues or chat about them on https://github.com/openSUSE/openSUSE-git/discussions
Looking forward to your feedback and issues raised.
Thanks, Dirk
-- SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nuernberg Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Hi Dirk, how does testing builds work with this new git-backend? Usually, I branch a package in OBS, do updates, send it back to my branch and see if it builds fine on all archs and relevant code-streams. Sometimes I even try out the resulting rpms, in case I need to verify some fix. And only once I'm satisfied, do I issue an SR. How does something like this work with the new git-based model? It seems to only actually start building something, once I've created the final SR/PR to Factory. But what if it gets approved before I could test out things or other codestreams/archs have finished building, that Factory doesn't care about? Thanks, Martin On 6/26/24 2:29 PM, Dirk Müller via openSUSE Factory wrote:
Hi,
for a while src.opensuse.org has been serving git-converted history of openSUSE Tumbleweed packages. We recently switched that to SHA256 which is the git format chosen for package maintenance in git going forward. We are aware of many unsolved issues but are afraid to miss some others. Therefore I'd like to invite you to opt in maintaining some of your existing packages in git and help us find and resolve issues in the tooling (osc, and maybe anything else you're using).
The way on how to do that is documented in https://opensuse.github.io/scm-staging/user_guide.html#contributor-guide
This is a bot that forwards PRs from one place to SRs in the other place. This is a migration helper, it's not supposed to stay that way, so don't focus on this part too much. the interesting part is learning what else you need over today in making the "local packaging experience as good or better" with package sources stored in git.
feel free to report the issues or chat about them on https://github.com/openSUSE/openSUSE-git/discussions
Looking forward to your feedback and issues raised.
Thanks, Dirk
Hi Martin, Martin Sirringhaus via openSUSE Factory <factory@lists.opensuse.org> writes:
Hi Dirk,
how does testing builds work with this new git-backend?
Usually, I branch a package in OBS, do updates, send it back to my branch and see if it builds fine on all archs and relevant code-streams. Sometimes I even try out the resulting rpms, in case I need to verify some fix. And only once I'm satisfied, do I issue an SR.
How does something like this work with the new git-based model?
It seems to only actually start building something, once I've created the final SR/PR to Factory. But what if it gets approved before I could test out things or other codestreams/archs have finished building, that Factory doesn't care about?
At the moment you have to create a pull request on gitea to get a build automatically created for you. In theory you can setup a project on OBS with <scmsync>, but this is atm a manual process. 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 Thu Jun 27, 2024 at 9:29 AM CEST, Martin Sirringhaus via openSUSE Factory wrote:
how does testing builds work with this new git-backend?
https://github.com/openSUSE/openSUSE-git/discussions/40 -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 The only time to eat diet food is while you’re waiting for the steak to cook. -- Julia Child
On Wednesday 2024-06-26 14:29, Dirk Müller wrote:
The way on how to do that is documented in https://opensuse.github.io/scm-staging/user_guide.html#contributor-guide
The doument says to use 5. Modify the package meta of the devel package via <scmsync>https://src.opensuse.org/pool/$pkg_name#factory</scmsync> However, as I am trying to convert some packages, this raises doubts and feels wrong. What would make more sense to me: * openSUSE:Factory/pkg_name should have <scmsync>https://src.opensuse.org/pool/pkg_name#factory</scmsync> * devel:project/pkg_name should have <scmsync>https://src.opensuse.org/pool/pkg_name#master</scmsync> or perhaps even <scmsync>https://src.opensuse.org/somedevelprj/pkg_name</scmsync>
Hi Jan, Am Do., 27. Juni 2024 um 17:58 Uhr schrieb Jan Engelhardt <jengelh@inai.de>:
However, as I am trying to convert some packages, this raises doubts and feels wrong. What would make more sense to me:
* openSUSE:Factory/pkg_name should have <scmsync>https://src.opensuse.org/pool/pkg_name#factory</scmsync>
That might be the end goal, but it is currently not possible as you can not do SRs to packages that have scmsync tag set. it is an intentionally missing feature of the build service. And until we can improve the rest of the tooling, Factory release maintainers are not going to switch to a git workflow because it means all their tooling needs to work with that as well. So for now, this is not possible. eventually it will be.
* devel:project/pkg_name should have <scmsync>https://src.opensuse.org/pool/pkg_name#master</scmsync>
For now, noone will have write access to /pool, so the #devel/master idea does not work.
or perhaps even <scmsync>https://src.opensuse.org/somedevelprj/pkg_name</scmsync>
Yes, we can take a look at that also. I'll put it on my todo. Greetings, Dirk
participants (10)
-
Alessio Biancalana -
Axel Braun -
Bernhard M. Wiedemann -
Dan Čermák -
Dirk Müller -
Jan Engelhardt -
Marcus Meissner -
Martin Sirringhaus -
Matěj Cepl -
Michael Pujos