branching the debian-cloud-config repository for stable support
At some point, maintaining config for our stable images in the same
repository as our unstable/testing images is going to become
unmanageable. We'd like to be able to make changes targeting unstable
without worrying about breaking our stable builds.
Consider the following simple case. I'm working on packaging
amazon-ec2-utils, which I'd like to add to the default installation once
it's available. To do that today, I'll need to add release specific
configs to package_config/EC2, or add EC2 specific stuff to
package_config/{BULLSEYE,SID}. It's manageable, but clunky. When we
start talking about config files that are specific to combinations of
releases and/or architectures and/or cloud providers, it gets even
worse.
So here's a proposal for handling stable releases. I think this solves
our problems without crazy ongoing effort:
1. We create a 'buster' branch all our image build repos
(debian-cloud-config, debian-cloud-images-daily,
debian-cloud-images-release)
2. The -release and -daily master branches stop building buster images.
Specifically, we remove buster from the .gitlab-ci.yaml file. These
branches continue to track the master branch of 'debian-cloud-config' in
their tools submodule.
3. The buster branch in the -release and -daily repos tracks the buster
branch of 'debian-cloud-config' in its tools directory. This branch
drops everything *except* buster from .gitlab-ci.yaml.
4. We set up salsa pipelines to run for both the 'master' and the
'buster' branches for the daily project. The release project only needs
to build the buster branch.
Once this is done, we can continue working in master in the
debian-cloud-images repo without risking breaking buster. It sets us up
with a reasonable strategy for future releases as well.
Does this seem sane? Any other ideas?
noah
Reply to: