Git packaging workflow for Salt

[agraul]

Alternative to #96

Rendered at https://github.com/agraul/uyuni-rfc/blob/git-packaging-workflow-salt/accepted/0000-git-salt-packaging.md

Examples:

• Salt package-git: https://src.opensuse.org/agraul/salt
• Salt Extension package-git: https://src.opensuse.org/agraul/python-saltext-apache
• Salt project-git: https://src.opensuse.org/agraul/salt-prj (this will be named something like salt/_ObsProj at its real location)
• OBS Project (where it's built): https://build.opensuse.org/project/show/home:agraul:salt-prj (build failure is due to old salt.spec from a PoC branch I didn't fix)
• Makefile used to update Salt across branches: https://gist.github.com/agraul/9ba65ba75100a8dd8462f91703d0a580

[meaksh]

I really like this approach more than what I proposed in #96. It is aligned with the new TW / SLE16 workflow.

Just raised some initial notes for now.

[meaksh]

This is what feeds the salt-doc package. We use to create this tarball when bumping to a next major version by compiling the documentation locally.

In the past, compiling the documentation during build time was causing problems and that's why it was compilled locally and provided via tarball.

[agraul]

I'll check if we still have issues compiling at build time. We could have the tarball in git lfs if that causes issues.

[meaksh]

In the past, it was tricky to build doc during buildtime in all different OSes where we were building the classic package (as sphinx version and deps were not compatible in some of them).

[meaksh]

This is where the D:G:M:Head points to, so devel Salt for the next MLM version.

I think we should keep it. We could think on using factory here instead, but I think having next gives us more flexibilty in the scope of MLM, as it could be that saltstack/salt has different cadence (version) than the one we want for our future MLM version.

[agraul]

I guess the question is if we want to have a separate cadence. We currently have two devel codestreams, next and factory, but only work on one at a time. I'm not sure if it's useful to keep two.

[meaksh]

IMO one of the benefits of having a separated next environment is that it allows us to put a devel/unstable package there (usually next major version), where we also execute the acceptance CI on it, allowing us to catch possible issues there without touching the obs://systesmanagement/saltstack/ package.

That way, we keep the factory branch and the package at obs://systesmanagement/saltstack/ being always "stable", where we don't use it for testing unstable-next-versions of salt package.

[agraul]

The package in systemsmanagement:saltstack is the devel package. The non-devel package is in openSUSE:Factory. I don't really see the need to have two devel code streams. When 3008 is available, we should bring it to openSUSE:Factory as soon as possible (via systemsmanagement:saltstack). Using another location and then copying it over is only useful if we want to release other updates in between.

[agraul]

I've been thinking about the branch setup and one part I didn't know about when I wrote the RFC is the organization on src.opensuse.org for the distributions. I think we'll have actually two repos: pool/salt which is the place that distros pick the package from and a fork in our own organization (e.g. salt/salt). The latter is only needed to easily test Salt together with Salt extensions, at a different pace than we create package-level SRs.

With the fork in place, we essentially have a devel branch for each product/release branch

[vzhestkov]

Branches of pool/salt for src.opensuse.org and src.suse.de are described below, but the purpose of salt/salt and it's branches is not described. Should we have it described here?

[agraul]

Our fork contains the same set of branches as pool/salt and is used to test and develop Salt together with extensions.

That's what I currently have, what would make this clearer to you?

[vzhestkov]

In this case better to change Our to This, maybe it was caused my question here as now when you pointed to it, it became clear, but originally most probably I was confused what Our fork means, maybe it was expanded in my brain to openSUSE/salt in github :-D