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". josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
