On Mon, Aug 07, 2017 at 07:33:21AM -0400, Josh Boyer wrote: > On Sat, Aug 5, 2017 at 10:57 AM, Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> 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"? P
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
