Prologue: Neither of these may be possible in F20. releng needs to test
whether any of this is possible and figure out what work would be needed to
get this to happen.
A straw poll was taken on the ideal branch layout. Unlike the filesystem
location, support for the various ideals of what branches should look like
was mixed. In the end, there were 4 people for having scl-ified spec files
separate from mainstream packages and 1 person for giving maintainers the
choice of which path to pursue but only a few people felt strongly either
way (2 for separate and 1 for maintainer choice).
Here's how I presented keeping scl-ified spec files separate:
releng issues aside, the goal is to have one package for all scl versions
and one package for the mainstream version. Inside of the mainstream
version, there will be a branch for each fedora release (just like now).
Inside the scl version, there will be a branch for each scl+fedora version
combination. The master branch of the scl version will be a clone of the
mainstream package master. SCL macros will only occur in the scl git, not
in the mainstream git.
Here's how I presented having them combined:
They [the scl team] want to be able to have a single git repo for each
package. there would be scl+fedora version branches inside of there as well
as the fedora version branches for mainstream versions. the mainstream
packages can have scl macros. all macros are conditionalized so that they
only apply when building an scl.
A proposal was also made that each scl+package combination should get a separate
package in the git repo. The rationale was that spec files would likely
have to differ just by nature of upstreams changing things between versions
of their upstream package. I think we'll have to discuss this more but my
instinct is that we'll find that some spec files will remain the same between
scls because they aren't the primary purpose that the scl is being built and
thus they can both be at the same version. So it makes sense to share spec
files for different scls. (Note - this is nearly identical to our fallback
for F20/F21 in case releng finds that we can't do any sort of
scl-in-branches without tooling changes. But I still don't think this
should be the goal that we shoot for.)
So what's the impact here? If we go with a separate package for all scl
work, we can remove the conditionals from the guidelines. General SCL
packages will have the scl macros. Mainstream packages will not. Packagers
(provenpackagers, new maintainers taking over a package, etc) won't have to
worry about scl macros unless they're actually interested in the general
scl packages. If we make combined our ideal then packagers who do want to
shepard their package as a general SCL package and a mainstream package will
be able to share changes between the mainstream and SCL packages more
easily. The cons are basically the reverse of those, combined means higher
barrier of entry for packagers who then have to learn about scl packaging in
addition to mainstream packaging. Separate means changes in the mainstream
package might take more work to prot to the general SCL package.
-Toshio
