On 11/27/18 11:39 AM, Owen Taylor wrote:
We can definitely talk about whether moving to a slower cadence for
certain parts of the base platform. But people don't judge Fedora on
how beautifully we maintain glibc and gcc - they mostly judge it by
installing it on a laptop and seeing how well it works. And it doesn't
really matter how reliably we can create minimal container images if
the workstation image doesn't compose or doesn't log in.
It's true that the #1 use case for Fedora is the desktop, but that
isn't all Fedora is used for. If Fedora is going to continue to grow
it needs to serve more uses. At the same time it needs to keep doing
a great job as a desktop- so we have to look at solutions that promote
both.
How beautifully we maintain platform pieces like gcc, glibc, and other
commonly used shared libraries is actually tremendously important to
many users, to many developers, because it affects their ability to
adopt Fedora as a base to do the things they want to do.
We need clear naming for the workstation releases we do. If we want to
call them F30, F30.1, F31, F31.1 we can, but that doesn't inherently
reduce load on releng or remove the need for infrastructure freezes
... my assumption was that the idea of delaying F31 is to actually
*not* do an operating system release for a year, and that's something
that I don't think we should do on an ongoing basis.
Paul's proposal was definitely a one-time pause for the reasons you
state. He requested we follow-up with additional questions and
suggestions so I'm questioning and suggesting taking it a step
further. We talk about rolling releases, but people are skeptical due
to rawhide instability. What does it look like if the "rolling"
happens on top of an otherwise stable platform where fundamentals like
compilers, libraries and core system tools are held steady, but things
on top move fast? Maybe you don't need an F30.1, maybe it means F30
just keeps getting nice incremental updates for as long as the
editions want to stick with it. Variable lifecycle or cadence can
open up these kinds of options. Some things are better fast. Some
things are better slow.
Owen
On Tue, Nov 27, 2018 at 1:19 PM Brendan Conoboy <blc@xxxxxxxxxx> wrote:
On 11/27/18 10:13 AM, Josh Boyer wrote:
On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor <otaylor@xxxxxxxxxx> wrote:
On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor <otaylor@xxxxxxxxxx> wrote:
But for the next thousand or so Fedora developers, the release cycle
is actually not a big deal - not something that takes much of their
time - and it gives them a regular place to land feature work. And
Fedora users appreciate a timely updated operating system (without
having random rebases trickle in.)
It's not a big deal because they don't participate in making the
release nor do they really know about all the duct tape and bailing
wire holding all the machinery in place. Just like most of them don't
appreciate the heroics involved from Fedora QA and rel-eng and the
dozen or so people that regularly go well beyond the extra mile to get
it out the door. This isn't done out of malice on their part. It's
mostly that they just don't see it.
If we distribute this work out across the 1000 developers, we'll make
life better for heroes, and it's *still* not going to be a big deal
for the 1000 developers.
I would say it will be a learning curve and there will be complaints
because it's change and people seem to only want change if it's the
change they want or otherwise doesn't impact them. That's going to be
a big deal to some :) Generally though, yes. We need to distribute
the burden to the package sets and whomever maintains them.
In other words, the "technical debt" we are trying to solve here is
not project wide and doesn't justify slowing down the whole project
permanently.
I completely disagree. Our release process and tooling is built on
heroism and tech debt. At some point, that is going to cause
significant burnout and then people will just wonder what happened
when those people stop doing releases. I think it's better to raise
awareness at the project level, and build something that is
sustainable rather than predicated on "small group of people killing
themselves for the greater good". That starts with individual package
CI gating, and goes all the way through integration testing between
packages in a gated manner, into how we actually *create* all of that
plus the things we deem worth of releasing.
I think you are misunderstanding me somehow. I'm 100% on-board with
improving the processes, catching compose problems in an automated and
early fashion, making developers fix their own problems, and generally
making releases a less heroic process. And if that requires a
temporary cadence chance to get the retooling done, then it's worth
it.
Ah, good!
But Brendan's proposal to permanently slow down the cadence seems to
make the assumption that the current release cycle is a heroic effort
for the entire project - that we're moving too fast to stay on our
feet. And I don't think that's the case.
That would be a concern to me as well, assuming we stuck with a
*single* cadence and a *single* platform. With the lifecycle
Objective, aren't we targeting multiple cadences and lifecycles? I
mean, we have this today with Fedora Atomic/CoreOS vs. "regular"
Fedora. Maybe Brendan was thinking singular, but I would very much
like the ability in our tooling a process to have both the faster
moving cadence of today AND a slower moving one. That's another
reason I view a temporary halt as worthwhile. If done correctly, it
enables Fedora to fill more usecases and lifecycles than we could ever
accomplish with a single release.
Josh has it: I am indeed thinking about how this works with the
lifecycle objective. When we think about things as all or nothing we
rapidly get into a zero sum game: Let's make this part of Fedora worse
to make this other part better. We don't have to do that, we can just
make Fedora better. That's what having multiple cadences and
lifecycles is all about. So it is important to talk about how the
rules would change if F30 takes a year, because if the rules don't
change it might diminish one of the great things about Fedora.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
