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
Attachment:
pgp3gc9TnWH5q.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
