Re: branching the debian-cloud-config repository for stable support

2020-05-10 Thread Bastian Blank
On Fri, May 08, 2020 at 04:29:16PM -0400, Noah Meyerhans wrote:
> 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.

Please take a look at package_config/AZURE, where such a change was done
for cloud-init.  While a bit verbose, I don't consider that 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.

With existing support we can AND two classes.  Do you see some change that
would need three?

My problem with all of this is:
You are trying to optimize for something that happens now only the
second time now during this release cycle and also doesn't even need
workarounds to get right.

However you miss the whole lot of other changes that don't change how we
build stuff, but how we transport, modify and finalize images.  And
there have been significant changes during this time period.  Some of
them have been breaking changes.  And a lot of them also needs to done
to the tools used for stable stuff.

So a typical change to not build stuff would now require
- merge into master and
- merge or cherry-pick master into buster and look out for stuff that
  must not be merged.

Regards,
Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown



Re: branching the debian-cloud-config repository for stable support

2020-05-08 Thread Noah Meyerhans
On Fri, May 08, 2020 at 11:41:55PM +0200, Bastian Blank wrote:
> > Does this seem sane?  Any other ideas?
> 
> Nope, it is not really.  The daily and release projects needs to use
> current tools, without it diverging between the branches.

I'm not sure I agree.  A lot of important details about the structure of
the image and how it's represented at the provider's service come from
tools, so the tools that build our stable releases need to stay stable.
Details like the image names and the list of FAI classes used to
generate the image come to mind.

> So we need to split tools and config space then and solve the
> compatibility problem on that level.

Where would you have the split?  Separate config_space from tools, and
have config_space be handled as separate (per branch) submodules?

noah



Re: branching the debian-cloud-config repository for stable support

2020-05-08 Thread Bastian Blank
On Fri, May 08, 2020 at 04:29:16PM -0400, Noah Meyerhans wrote:
> Does this seem sane?  Any other ideas?

Nope, it is not really.  The daily and release projects needs to use
current tools, without it diverging between the branches.

So we need to split tools and config space then and solve the
compatibility problem on that level.

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6