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".

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

Reply via email to