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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
