Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/09/2016 02:52 PM, Matthew Miller wrote:
> On Fri, Dec 09, 2016 at 08:50:06AM -0800, Adam Williamson wrote:
>>> So, *did* you feel that the F25 cycle felt compressed? If we're close
>>> enough to the theoretical-world above that we feel like we can do, say,
>>> four month cycles to stay on track without experiencing (particular)
>>> pain, maybe that's okay.
>> This seems like an impossible question to answer. Our release cycles
>> are entirely arbitrary; they're precisely what we say they are. So I'm
>> not sure how to say whether one "feels compressed", or understand how
>> "four month cycles" would make us "stay on track". *What* track would
>> we be staying on?
> Roughly Mother's Day / Halloween, and not unpredictably cycling around
> the calendar. Entirely arbitrary in general, in the sense that we make
> them up is fine. Entirely arbitrary *each time* where we don't know
> where they'll be in the future until after the current release is done
> is bad for users, Fedora developers, upstream developers, downstreams,
> and basically every group I can think of.
>
>> you're proposing sounded like a large amount of work for (particularly)
>> release engineering, but came with no clear justification beyond "I
>> have an unquantifiable feeling that we can get better press coverage if
>> we do one release a year", which is extremely thin. At a bare minimum,
>> any significant release cycle change needs to come with a ground-up and
>> coherent justification of why *that* is the best way, right now, for
>> the Fedora project to produce little baby Fedoras.
> I'm sorry — I'll blame some of this on what Smooge said, about emailing
> ideas from the conference floor. I didn't mean for the release adoption curve
> and PR cycles to be the justification — that's just what got me
> thinking about it right now.
>
> I'm not sure what the best way is, right now.
>
>
>> It also seems bizarre to be having a 'release' conversation that
>> doesn't really seem to tie in at all with what's going on with
>> Modularity and Factory 2.0...since I thought those were the primary
>> drivers of planned major change to how we deliver Fedora.
> Somewhere back in the early part of one of these threads, that *was* in
> there — Generational Core on _three month_ cycles following new kernel
> releases, userspace modules updated on their own natural cycles, and
> big release events annually.
>
> Langdon is sitting right next to me right now and I'm going to tag him
> in for more on Modularity.
>

So, what I hope for with gen-core/modularity is that the decision to 
"release" becomes entirely unrelated to engineering. In other words, at 
any given time there is a fully working/fully tested, up to date 
gen-core and all the applications (or modules) that sit on it. Those 
applications will also, likely, be able to run on multiple gen-cores. As 
result, the processes to produce working artifacts that users can 
install will always be running. Hopefully, with enough CI (read: 
automated testing) that there is little to no human involvement in 
ensure that everything is in "good shape."

If we can get to that point, then we can make "release" and "lifecycle" 
decisions purely based on the desire of "not code" reasons. In other 
words, we can decide how many versions of things are currently available 
based on the effort required to maintain them. We can also decide when a 
"release" makes sense based on marketing or other considerations and 
just "pull the trigger" on that day. Or we could allow users to decide 
for themselves by opting in to a "rolling release" style of deployment.

Right now, we decide on the server-side when a "release" happens for 
lots of reasons. In the modularized world, there is no reason that we 
can't let users decide when they get new versions of things and they may 
even want different rules for different software. Or, as that is likely 
to be pretty confusing (particularly at first) we could have the 
Editions decide their policies/releases and have the client tools 
"enforce" them.

Langdon

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