Well, I have read tons of things, and only one thing bump in my head: "Ubuntu LTS"
I mean, it's a great idea, and a lot of people have asked about it in forums, reddit, twitter, fedoraforums and the list goes on. I thing that if someone can make it happens is the awesome Fedora Developers team, but actually my concern is in how to avoid the comparison, or being called copycats, or put in doubt both originality and innovation. I know is probably too early, but give it a thought from the point of view of the marketing: How we can advertise a product that others have?
Br,
El jue., 15 nov. 2018 a las 21:46, Jason Tibbitts (<tibbs@xxxxxxxxxxx>) escribió:
>>>>> "MM" == Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes:
MM> Let's talk about something new and exciting.
I assume that you mean "very much not new and about as exciting as the
fifteenth viewing of an episode of the Joy of Painting".
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.
For the life of me I simply can't remember the various proposals called
their releases, though.
One example of what I'm talking about is
https://kanarip.fedorapeople.org/Fedora%20Extended%20Lifecycle%20Support%20-%20The%20why,%20the%20what,%20the%20how%20and%20the%20who.pdf
but that came after I stopped paying attention to this kind of thing.
In the end the discussions I recall seemed to come down to a few basic
things.
1) A lot of people would love to consume such a release.
2) Not nearly as many actual maintainers would want to do so.
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.
4) Someone has to do release engineering. Even in the earlier days this
was seen as something that wasn't going to happen.
My recollection is that meaningful discussion usually stopped at the
kernel issue. At one point we had some basic agreement that people who
cared were welcome to push to old branches of things to keep them going,
but that was back when we had per-branch ACLs. But that never happened,
and as there was no effort to actually compose updates for those
releases, it doesn't matter much anyway.
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.
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.
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.
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.
- J<
_______________________________________________
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
--
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
_______________________________________________ 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
