openSUSE / openSUSE-git

3 stars 5 forks source link

Allow optionally to stage from devel project #23

Open dirkmueller opened 1 year ago

dirkmueller commented 1 year ago

Currently, the scm-staging bot is creating its own new project / package for submitting a SR into the main distribution. Allow to optionally configure it to use a "persistent" devel project from which the change can be submitted into the main distribution. This requires the permissions in OBS to be set so that the bot has direct write access and probably some devel project naming configuration in the git repository.

dcermak commented 1 year ago

Dirk Mueller @.***> writes:

Currently, the scm-staging bot is creating its own new project / package for submitting a SR into the main distribution. Allow to optionally configure it to use a "persistent" devel project from which the change can be submitted into the main distribution. This requires the permissions in OBS to be set so that the bot has direct write access and probably some devel project naming configuration in the git repository.

Wrong repo?

dcermak commented 1 year ago

Currently, the scm-staging bot is creating its own new project / package for submitting a SR into the main distribution.

That is one of the two possible approaches. Currently the bot can either directly submit the package to the destination project or it can send them to the configured devel project.

Allow to optionally configure it to use a "persistent" devel project from which the change can be submitted into the main distribution. This requires the permissions in OBS to be set so that the bot has direct write access and probably some devel project naming configuration in the git repository.

I don't think that the bot should commit directly into a devel project. Also, I thought that the final goal was to get rid of devel projects altogether.

Hence I don't really understand the goal of this card/task.

AdamMajer commented 1 year ago

devel projects are still useful especially since other projects are not automatically rebuilt when dependencies are updated. For example, if we have package that is sent to SLE-15-SP4:Update, that package will not be rebuilt in the target project. So it becomes more difficult to notice when regressions could creep in.

In the current instance, we don't need devel projects either, just submit to Factory and have maintainers ack that there. But it's just less messy when you can see build status across different target projects first.