On Mon, Aug 07, 2017 at 07:33:21AM -0400, Josh Boyer wrote:
> On Sat, Aug 5, 2017 at 10:57 AM, Matthew Miller
> <mat...@fedoraproject.org> wrote:
> > Our Change process has the basic assumption that if a Change isn't
> > working, we will be able to back out. But, in practice, when there are
> > problems, we often find it that it's easiest to shrug and go forward,
> > scrambling to fix problems in the change itself as well as any fallout.
> > I won't say this is a _failure_ exactly — with the Change process, at
> > least, we do have that checkpoint where we know the scramble is needed
> > rather than waiting until the very last minute. But, especially if we
> > are serious about a six-month schedule, it'd be _better_ if we could
> > simply decide at the Change Checkpoints whether to include the feature
> > at all.
> >
> > Arbitrary branching and Modularity give us a way to do this. We can, at
> > any time, say "this release includes this set of modules" (see
> > https://docs.pagure.org/modularity/design/constructing/compose-distribution.html
> > and
> > https://docs.pagure.org/modularity/design/constructing/back-together.html).
> >
> > I'm really liking what I'm seeing from the Boltron demo, questions
> > about how to actually manage modules as an end user notwithstanding. If
> > we can deliver this with minimal end-user disruption and yet give
> > ourselves capabilities like this, it's a huge success.
> >
> > (Aside: This possibly involves what the Boltron walkthrough calls
> > "system profiles". Modularity team! This isn't in the docs yet. Can you
> > clarify?)
> Hm.  I agree entirely with you, but when reading this I thought of
> another possibility.  I think modularity gives people the option for a
> rolling release, where we don't have to make release == "collection of
> specific module versions".  If that's one of the outcomes, then
> Changes simply become "this module version is available".

I agree.  Once everything is modular, distro-wide release changes
stop making sense.  Instead we should be proposing changes for
modules -- announcements of streams and such.

Fedora release could/should still be driven by a set of low level
modules, such as Platform and a few more tightly linked with it.

Would it make sense to split the compose into two or more in this
case?  "Platform and stuff" + "Other, mostly independent stuff"?


Attachment: signature.asc
Description: PGP signature

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to