Quoting Matthew Miller <mattdm@xxxxxxxxxx>:
I'm not able to force anyone here to do anything. Therefore, I have to
That's the first problem... You either need to be able to force them to do the right thing, or punish them for failure. If you can't do one or the other of those then you're screwed, to put it bluntly.
encourage good practice entirely via "carrots".
"sticks" work also. You get hacked, we unplug you from the network until you comply. Gets their attention real fast when they are removed from the network. Works better than carrots actually, in the long run.
This works best when we align with the academic year -- a release in the spring, current through the following summer to allow time for upgrades. Ideally, *two* years and a summer, but I understand that's not practical.
13 months for two versions gives you a lot of time IMHO...
As it is, what will happen is: whatever Fedora release is current as of June-July-August will get installed on people's systems, and, with goading, upgraded the next summer.
Upgraded in the summer, whether the summer of the same or next year, and the problem is solved for 99% of the cases... Only way that fails is if you install early in the year (from January to April) and the next release is done right after school (fall) starts that year... In which case, that will hopefully be a small number of machines which you can knock off during winter or spring break, leaving the majority until the summer. The draw back of the above of course is you need to track all the machines, their versions, and installation dates, and keep that data updated. Basically you need a good DB of the machine information...
If the actual Fedora release happens to be new in June-July, the 13-month plan will be great, but if the latest release was from, say, January, that leaves a big hole in which systems *will* get broken into.
If you install in January, then just upgrade in the summer if a new release is out by then. See above for the rest of the details. I suppose there could be a small hole, which is why most release cycles are 1.5 years instead of 1.08 years... But your call for 2.5 years seems way too long for a project that wants to be cutting edge (and which you point out your users want because it is cutting edge. If they want cutting edge, they need to upgrade once a year, or else they are not cutting edge anymore).
panning out, and how it fits with merging Extras and Core. The availability of Extras is currently a huge draw for Fedora over CentOS.)
CentOS has Extras/Plus also for a lot of packages... And there are lots of other packagers making "extras like" repositories out there... For the "desktop" user this should be more than sufficient. It may of course violate "server" or "production" users who have QA issues with that type of thing. In fact, one advantage of RHEL over FC/CentOS/anything-completely-opensource is it actually comes with non-opensource software that is commonly desired, and which is kept updated for security problems...
Extending the lifespan from ~9 to ~13 months is a huge help, but to cover the gaps, we really need more like 18-19.
I really disagree. The project is to be cutting edge, your users want cutting edge, the only way to do that is to upgrade yearly. Otherwise, both the project and your users are not cutting edge. If you can't manage the upgrades in a year, then you need to hire more staff locally (or better automate your upgrades). Now, I really do feel for you and your situation. But I don't think you can impose your bad situation on the Fedora Project, when you claim your users really do want the same thing as Fedora Project, which means you really do need to upgrade yearly, and not every 2.5 years. Fedora Legacy is doing your users a disservice IMHO by not allowing them to be cutting edge as they want to be. In your case, I would think the only way to meet your needs would be with Fedora Legacy, as Fedora Core just can't do 2.5 years of support and meet its mission. But I'm not sure there are enough people in such a unique situation, and who are so fixated on Fedora Core over other distributions, to sustain something like Fedora Legacy. Of course, I could be completely wrong... :) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legacy-list
