On Thu, Nov 15, 2018 at 05:54:59PM -0600, Jason Tibbitts wrote:
> MM> Let's talk about something new and exciting.
[...]
> I know it's been a while. Maybe it's been long enough that a
> significant number of the developers here don't remember it. I am
> pretty sure you were around, though, so I do hope you have some
> recollection of it. Put simply, Fedora has had this discussion before.
> A number of times. Going back to FC1 and what the release cycle would
> look like. At one point it was basically an endless thread that lasted
> the better part of a year.
Okay, sure, how about: something we haven't talked about seriously in a
long, long while. That proposal from Jeroen is from 2011. I think that's
long enough that it's okay to look again.
> 1) A lot of people would love to consume such a release.
> > 2) Not nearly as many actual maintainers would want to do so.
>
Yep, yep.
> 3) At minimum, we need a kernel. Which means we need a kernel team. I
> doubt the current kernel team would be any more enthusiastic about
> either backporting everything, maintaining packages of the extended
> lifetime kernel packages (assuming those even line up with the
> release schedule) or pushing the current kernel back to the
> equivalent of... Fedora 25 or so.
I think things are different here for several reasons:
1) Upstream LTS kernel now.
2) Investments in Fedora kernel CI may change the landscape
3) See Brendan's comment on "middle layer" stability. Faster moving kernel
may be just fine.
3) Depending on outcome of our community conversation, Red Hat may be
willing to put in some resources.
> 4) Someone has to do release engineering. Even in the earlier days this
> was seen as something that wasn't going to happen.
Right; that was basically a "what Red Hat is willing to fund" thing. Fedora
Legacy demonstrated that it's possible but very very hard to sustain without
ongoing funded positions. But this is not necessarily a blocker going
forward.
> And now we're bigger, and there are more big systems that would need
> maintenance. Oh, and we have a security team now; they'd have to deal
> with issues in those old releases. And more big package sets like
> Python and Node and Go and whatever, some of which amount to a larger
> number of packages than made up the entirety of one of the old Fedora
> releases. Hello, Python SIG? Good luck finally getting rid of
> python2. You get two more years of support backporting security fixes
> and you don't even get paid for it.
I agree that we can't possibly commit to long-term maintenance for the whole
distro. That's part of why I've been on about all this rings and modularity
stuff. :)
> And to add in an additional argument that we didn't have a decade ago:
> We're actually trying to evolve our packaging now. EPEL with it's "old
> RPM never changes" restriction is bad enough but fortunately limited in
> scope. Having years of Fedora releases that can never evolve but which
> still hold back progress in Rawhide is just too much.
I don't think we'd necessarily be held back in that same way. "RPM never
changes" wouldn't need to be something we'd hold to. ("RPM not replaced with
pacman" is a different story.)
> Really, this is what our downstream distributions RHEL and CentOS are
> for. That was the answer then and I don't see why it doesn't still
> apply.
There are sectors where this is important where those distros aren't the
best fit. Red Hat is not interested in an end-user desktop market. Red Hat
isn't making an edge-devices IoT thing. And there is a lot of academic use
where Fedora is a better fit than either but which we are not selected due
to bad alignment with university IT needs.
> MM> How would we balance this with getting people new stuff fast as
> MM> well?
> Wait, what? Certainly you're not suggesting trying to do an extended
> lifecycle that also gets all the new stuff. That's seems like a
> contradiction in terms.
It's the fundamental contradiction that all operating systems face: users
complain "too fast and too slow!" at the same time.
As noted elsewhere in this thread, many packagers are already doing this:
maintaining a slow stream for EPEL or for RHEL as part of their day job, and
a fast stream in Fedora. SUSE manages to integrate this together with Leap;
because of our multi-brand puzzle, we've been kind of blocked from taking
advantage of what we have. But that's really an artificial block; it's all
open source, all very similar technology, and all in the same family, even!
--
Matthew Miller
<mat...@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
