On 12/20/2016 08:20 AM, Matthew Miller wrote:
On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote:
I probably lost the context ... what real-world problems are trying to fix?
Everything which comes to my mind should be solved by better tooling for
updates-testing testers.
I've given this in several ways across the thread, but I don't mind
restating. :)
1. I believe in the value of releases, for the project and for end
users — as opposed to a "rolling release" system. But major releases
are a lot of work across the project — not just release engineering,
but marketing, ambassadors, design, docs, and others. One possible
way to reduce this is to have major releases less frequently. I want
a cadence that gives us the highest return on effort. Maybe that's
six months — and maybe it isn't.
2. I really want releases to come at a known time every year, +/- two
weeks. Keeping to this with six month targets means that if (when!)
we slip, the next release may only have five or four months to bake.
This doesn't seem like it's the ideal for the above — maybe we can
get the engineering processes streamlined enough to make it
comfortable, but there's still the matter of marketing and the rest.
3. The modularity initiative will mean that different big chunks of
what we use to compose the OS can update at different speeds and
have different lifecycles. That gives us a lot more flexibility in
the above, and I'd like us to start thinking about what we *want*
to.
I'd like to clarify what people have in mind here because it's pretty
fundamental to how to take the proposal. More on my interpretation below.
I suggested one release a year as an alternative to the current two per
year. I guess three per year would be possible (but seems counter to
the above); other plans like eight- or nine-month cycles don't have the
fixed-calendar property I'm looking for (and I'm pretty sure no one
wants to go to one every two years).
The proposals previously in this thread are ideas aimed at presenting
users with an annual release from a marketing/ambassadors/design, etc.,
point of view, but also addressing our upstream stakeholders' desire to
have Fedora ship their software fast. (For example, GNOME.) I hoped we
could find ways to make them also reduce release effort for developers,
packagers, releng, and QA, but from the feedback so far people don't
really feel like those particular suggestions do.
Another possibility would be to simply keep releases as normal but go
revist the "tick-tock" cadence we talked about a while ago: that is, a
May/June release aimed at features, and faster Oct/Nov release where we
concentrate on infrastructure — and then call that second release each
year the ".1".
And yet another possibility is that we keep things as they are. If
that's the overall consensus, okay. :)
You can't implement modularity *and* keep things as they are. So
here's how I take your proposal:
Once per year a new base Fedora release comes out. It has a nice new
stable glibc, gcc, etc. This is the content that all editions and
spins have in common.
Each edition or spin makes releases of their content layered on top of
the above package stream, but they can inject packages that are unique
to their edition. So the desktop edition can still make multiple
releases per year if they want, but they're layering on top of the
basic annual Fedora release.
Is that what people have in mind, or something else?
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
