On Wed, Oct 3, 2018 at 11:34 PM Paul Frields <stickster(a)gmail.com&gt; wrote: Thank you for proposing this. I hope you will inspire others to propose an objective too. This is a well structured document. Is the goal in defining the platform to have a platform definition that is a building block for all current project deliverables (editions, spins, labs)? this is awesome. I'd like to stress to others reading that you don't have to have this in order to propose an objective. What you need is a reasonable set of conditions that leads to you attracting people willing to help you make this happen. regards, bex -- Brian (bex) Exelbierd | bexelbie(a)redhat.com | bex(a)pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org

On Wed, Oct 03, 2018 at 05:33:18PM -0400, Paul Frields wrote: This looks awesome. One thing I'm missing is timeframes. Do we expect the "visionary goal" to be available at the completion of this objective in 12-18 months, or is that futher off? I guess kind of related, can we attach measurable numbers and dates to some of the key results? -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Fri, Oct 05, 2018 at 10:01:19AM -0400, Paul Frields wrote: Yeah, that's fair, but that can itself be the answer. How long is the discovery/investigation phase, and what will its concrete output be? How do we know that we've discovered and investigated enough? -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Tue, Oct 09, 2018 at 12:51:33PM -0400, Paul Frields wrote: That's fair. We want the Objectives to have a bounded scope; it may be that the end result is a SIG or other subproject, or some changes to the project that keep working but no longer need to be an Objective. Or, it may be that (as I think is likely here) the first phase will be followed by others, each with 12-18 month horizons. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Thu, Oct 11, 2018 at 04:14:10PM -0400, Paul Frields wrote: Make any updates and then submit a Council ticket at https://pagure.io/Fedora-Council/tickets/. Since Objectives are major project commitments, we will call for a full consensus vote, which requires at least three +1 votes from the core council and no valid -1 votes. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Sun, Oct 21, 2018 at 4:20 AM Brian (bex) Exelbierd <bexelbie(a)redhat.com&gt; wrote: One way to look at it is an expansion or follow-up to Modularity. In fact, many of the same people are involved. Bringing modularity to the distro, however, isn't the same as re-engineering the distro to support the lifecycle split we talked about at Flock. For now the Modularity WG is starting to track this work because of the cross over. In formulating the objective we decided it wouldn't make sense to make a completely different group. We might look at renaming to take on the expanded scope, but as long as we're clear about where community members can follow the action, that shouldn't be a source of confusion. -- Paul

On Sat, Oct 6, 2018 at 10:21 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote: Agreed -- I'll try to add that early in the discovery part so that we know there's broad agreement on that state. I have a few things in mind, like modernizing compose in a way that makes it more adaptable to other users, but we also need to be careful about not being too pie-in-the-sky. Right now, contributors have to line up behind a single process, with little latitude to own anything. We've made it easy to package lots of things, but we clutch tightly the reins that allow the community to own more of that process. It also means we have an extraordinarily large release surface that's a struggle, even though, for example, our QA and rel-eng teams are phenomenal. If we cut down what we need to encompass in a platform release, it potentially yields less material to track, compose, and test. But we can't do just that; we also need to give working groups, SIGs, and other contributors ways to release their stacks in a coordinated way outside the platform. Modularity is one way to do that, although there are likely others. From the user perspective, one benefit is additional options for the platform itself without requiring longer term maintenance of volunteer-provided packages. Others include less lag time for a popular new stack, and being able to have the same stack across multiple platforms (Fedora N-1 and N, for example). Dead? No way. But maybe "steady state" is a better way of saying it. We haven't tried extraordinarily hard in the past to carve out the platform like this. In one sense, that's probably because people are worried about engendering a "Core vs. Extras" worry from the old days of Fedora. That's not what this proposal is about. Even though we're talking about a content split, it's not designed to wall off the OS from community input or contribution. It's in service of letting us diversify what, how, and when we make -- IOW, making our process serve our goals, rather than letting the reverse be true. -- Paul