On Thu, Dec 8, 2016 at 1:18 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Thu, Dec 8, 2016 at 1:13 PM, Adam Williamson
> On Thu, 2016-12-08 at 09:17 -0500, Matthew Miller wrote:
>> Trying to make this idea a little more concrete. Here's two suggestions
>> for how it might work. These are strawman ideas -- please provide
>> alternates, poke holes, etc. And particularly from a QA and rel-eng
>> point of view. Both of these are not taking modularity into account in
>> any way; it's "how we could do this with our current distro-building
> Frankly, this all seems like a lot of churn and mess and process change
> for no very obvious benefit. I'm a hell of a lot more interested in
> looking at smaller and more frequent 'release' events than larger less
> frequent ones.
> Maybe I'm not understanding very well, but none of this makes me
> terribly excited.
Yeah I'm kinda thinking the same. Exactly what is the time frame for
atomic host? What work can be done to make that less hand wavy future?
If that's where we really want to be, then eat that frog rather than
coming up with more frogs.
Can kernel rebase act as a template for rebasing other things, without
the monolithic effort of a full release? How much time-effort is put
into creating testing qualifying and releasing images? That can't be
zero, but maybe it's not as big as it seems. The other pile of work is
stabilizing Rawhide from the time of branch to release, and in both
Option 1 and 2 that's being dropped. So how much time-effort happens
with that work? I sorta like the idea of branching off stable to make
a dot release but that means Rawhide ends up simmering much, much
longer than it usual does.