Hi folks. I've been a Redhat/Fedora user since RH9. I like it, but I wish there was an option that was a tad less aggressive whilst not being as stagnant or relatively featureless as RHEL (or CentOS). As I understand it, I'm far from alone in that wish.
I have an idea that may improve stability whilst limiting any downside. A brief description follows.
*****
To keep Fedora's identity and purpose, Fedora should maintain the aggressive 6-month release cycle and policy of upstream inclusions - that's no change from now.
BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release.
Shorten the odd-numbered release EOL to 7 months after release - that's one month after the next release. BUT, lengthen the even-numbered release EOL to 19 months - that's one month after the next "stable" re-spin is produced.
The main advantage is that it puts choice back in the hands of the user who can now choose to go from stable re-spin to stable re-spin (every 12 months) without ever touching the "bleeding edge" of Fedora, yet still gain the advantage of relatively new upstream inclusions that occured in the "aggressive" phase of that release cycle (the first six months) plus the progress gained from the previous odd-numbered release. And, the user can switch from aggressive to stable to aggresive, or any permutation thereof, at will, often (hopefully always) using upgrades.
Doing it this way, Fedora maintains its audience of thrill seekers and Red Hat retains its testing ground for potential inclusions. Uber thrill seekers still have Rawhide and a new release every six months, while more mainsteam users can upgrade to, or install, a "stable" re-spin annually while still doing things "the Fedora/Red Hat way". I expect newer users will be more attracted to the stable re-spins.
This might, and hopefully will, improve user-base growth. Based on my experience and interaction with other users, a sizable proportion of users would be pleased with the additional choice and option of enhanced stability. I expect newer users would be less likely to become frustrated (and possibly switch to another distro or OS) if they have that choice. It also might improve the result for Red Hat with higher conversions from Fedora users to corporate Red Hat users (I'm guessing that a larger and more satisfied user community must be a good thing).
By my thinking (which, of course, I can't promise is right), the workload placed on the Fedora Project shouldn't be much larger than today, if at all. The extra effort applied to even-numbered releases should be roughly cancelled by reduced effort on odd-numbered releases.
*****
So, over to the experts who actually build Fedora. Does the idea have merit?
anubis@iinet.net.au wrote:
Hi folks. I've been a Redhat/Fedora user since RH9. I like it, but I wish there was an option that was a tad less aggressive whilst not being as stagnant or relatively featureless as RHEL (or CentOS). As I understand it, I'm far from alone in that wish.
I have an idea that may improve stability whilst limiting any downside. A brief description follows.
To keep Fedora's identity and purpose, Fedora should maintain the aggressive 6-month release cycle and policy of upstream inclusions - that's no change from now.
BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release.
Shorten the odd-numbered release EOL to 7 months after release - that's one month after the next release. BUT, lengthen the even-numbered release EOL to 19 months - that's one month after the next "stable" re-spin is produced.
The main advantage is that it puts choice back in the hands of the user who can now choose to go from stable re-spin to stable re-spin (every 12 months) without ever touching the "bleeding edge" of Fedora, yet still gain the advantage of relatively new upstream inclusions that occured in the "aggressive" phase of that release cycle (the first six months) plus the progress gained from the previous odd-numbered release. And, the user can switch from aggressive to stable to aggresive, or any permutation thereof, at will, often (hopefully always) using upgrades.
Doing it this way, Fedora maintains its audience of thrill seekers and Red Hat retains its testing ground for potential inclusions. Uber thrill seekers still have Rawhide and a new release every six months, while more mainsteam users can upgrade to, or install, a "stable" re-spin annually while still doing things "the Fedora/Red Hat way". I expect newer users will be more attracted to the stable re-spins.
This might, and hopefully will, improve user-base growth. Based on my experience and interaction with other users, a sizable proportion of users would be pleased with the additional choice and option of enhanced stability. I expect newer users would be less likely to become frustrated (and possibly switch to another distro or OS) if they have that choice. It also might improve the result for Red Hat with higher conversions from Fedora users to corporate Red Hat users (I'm guessing that a larger and more satisfied user community must be a good thing).
By my thinking (which, of course, I can't promise is right), the workload placed on the Fedora Project shouldn't be much larger than today, if at all. The extra effort applied to even-numbered releases should be roughly cancelled by reduced effort on odd-numbered releases.
So, over to the experts who actually build Fedora. Does the idea have merit?
This has been discussed many time on the list, the problem is that you cant have it both ways, you cant have a LTS release with the latest and greatest. The only way a LTS release make sence is to freeze the code, test, test and test. And then backport security related fixes. RHEL/Centos does this well and Fedora does the latest and greatest part.
Tim
On Sun, Dec 21, 2008 at 07:54:31AM +0100, Tim Lauridsen wrote:
So, over to the experts who actually build Fedora. Does the idea have merit?
This has been discussed many time on the list, the problem is that you cant have it both ways, you cant have a LTS release with the latest and greatest. The only way a LTS release make sence is to freeze the code, test, test and test. And then backport security related fixes. RHEL/Centos does this well and Fedora does the latest and greatest part.
It is untrue. You can have a distribution which begins with the latest and greatest but is gradually stabilizing. You didn't read this proposal, did you? It has been retired, but you saw the discussions, don't you? https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EO...
-- Pat
Patrice Dumas wrote:
On Sun, Dec 21, 2008 at 07:54:31AM +0100, Tim Lauridsen wrote:
So, over to the experts who actually build Fedora. Does the idea have merit?
This has been discussed many time on the list, the problem is that you cant have it both ways, you cant have a LTS release with the latest and greatest. The only way a LTS release make sence is to freeze the code, test, test and test. And then backport security related fixes. RHEL/Centos does this well and Fedora does the latest and greatest part.
It is untrue. You can have a distribution which begins with the latest and greatest but is gradually stabilizing. You didn't read this proposal, did you? It has been retired, but you saw the discussions, don't you? https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EO...
-- Pat
No, i did not read then proposal and i read just read some of the discussion, these kind of threads quickly turns into a long pissing contest and I loose interest. IMO you have 2 nice choices in Fedora and Centos/RHEL and trying to put something in the middle is just wasting limited resources. But it is just my opion, you have another one, that is you right :)
Tim
On Sun, Dec 21, 2008 at 02:43:56PM +0900, anubis@iinet.net.au wrote:
BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release.
You are free to do this. The previous attempts to do this failed because not enough people could be bothered to contribute. If you can find some other folks who believe this is possible and between you the technical knowledge and large amounts of time required then go for it. Nobody is stopping you or anyone else producing updates to a Fedora release after its "officially" out of support.
Alan
On Sun, Dec 21, 2008 at 10:53:23AM -0500, Alan Cox wrote:
On Sun, Dec 21, 2008 at 02:43:56PM +0900, anubis@iinet.net.au wrote:
BUT, with every second release (I'll assume every even-numbered release), produce a re-spin at the 6-month mark, call it Fedora "stable" (or some such) and change the policy for updates and quality assurance at that point to maintain improved stability through to EOL - this may translate to fewer new features from that point to EOL but only within that release.
You are free to do this. The previous attempts to do this failed because not enough people could be bothered to contribute. If you can find some other folks
Last time it was not the reason why it failed. It failed because FESCo refused, and asked the board that certainly refused too. See https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EO... especially the discussion.
It could also have failed because of the lack of contributors, but it didn't went far enough to be able to judge.
-- Pat
On Sun, Dec 21, 2008 at 05:35:26PM +0100, Patrice Dumas wrote:
Last time it was not the reason why it failed. It failed because FESCo refused, and asked the board that certainly refused too. See
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
Alan
On Sun, 2008-12-21 at 12:14 -0500, Alan Cox wrote:
On Sun, Dec 21, 2008 at 05:35:26PM +0100, Patrice Dumas wrote:
Last time it was not the reason why it failed. It failed because FESCo refused, and asked the board that certainly refused too. See
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
Alan
Right, all FESCo did was decide to not spend Fedora Infrastructure resources on the venture until it had a proven set of producers and consumers.
On 12/21/08, Jesse Keating jkeating@redhat.com wrote:
On Sun, 2008-12-21 at 12:14 -0500, Alan Cox wrote:
On Sun, Dec 21, 2008 at 05:35:26PM +0100, Patrice Dumas wrote:
Last time it was not the reason why it failed. It failed because FESCo refused, and asked the board that certainly refused too. See
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
Alan
Right, all FESCo did was decide to not spend Fedora Infrastructure resources on the venture until it had a proven set of producers and consumers.
Yes, the kiss of death, practically speaking.
jerry
On Sun, Dec 21, 2008 at 09:29:00AM -0800, Jesse Keating wrote:
Right, all FESCo did was decide to not spend Fedora Infrastructure resources on the venture until it had a proven set of producers and consumers.
The infrastructure resource point was explicitly handled in the proposal. How can there be a proven set of producers and consumers if it doesn't exists yet? Proving that something is succesful before it is started This is a task that is impossible to achieve.
Besides the reason was not that reason, the final decision was left to the board. Many people on FESCo didn't like the proposal for various reasons, including the Infrastructure resources, but it wasn't the official reason. In fact I have never heard back the board answer, but I prefer not knowing how the board refused it.
There was also the joke about 'metrics', that are very difficult or impossible to set up in free software projects, and are especially not something in fedora -- nor EPEL. And that was a task to perform before another proposal in the past (UAEL) could be accepted. A way to say no in a authoritative way without saying it frankly.
Honestly, I would have preferred an authoritative answer like 'we don't want because we don't want to devote a single resource to that', rather than lame excuses and unfair impossible prerequisite tasks.
-- Pat
Alan Cox wrote:
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
But it's impossible to pull off without infrastructure, and setting up the infrastructure required for this project outside of Fedora requires months of work, and with the expected bandwidth requirements (think OO.o security updates), quite possibly also lots of money. That's why this project is doomed to fail without access to the official Fedora infrastructure, which is what was refused.
That said, with Patrice leaving Fedora, I don't think there's any driving force for such a project left anyway.
Kevin Kofler
On Sun, Dec 21, 2008 at 06:30:56PM +0100, Kevin Kofler wrote:
But it's impossible to pull off without infrastructure, and setting up the infrastructure required for this project outside of Fedora requires months of work, and with the expected bandwidth requirements (think OO.o security updates), quite possibly also lots of money. That's why this project is doomed to fail without access to the official Fedora infrastructure, which is what was refused.
In other words you don't have enough interest to make the project work. If you had enough interest you'd soon find bandwidth and infrastructure. The Debian project appears to manage this just fine and several of the well known current distributions started out as a small group of people.
Your infrastructure estimates are pretty ridiculous. If it takes you more than a week to kick start a basic build environment for doing security updates and you can't find a linux related site to host your stuff initially you are doing something wrong or don't have enough interested skilled people.
Remember Fedora existed originally as a volunteer additional set of repositories before it ever teamed up with Red Hat. They seem to have managed quite well as a volunteer project on their own.
Alan
Alan Cox wrote:
Your infrastructure estimates are pretty ridiculous. If it takes you more than a week to kick start a basic build environment for doing security updates and you can't find a linux related site to host your stuff initially you are doing something wrong or don't have enough interested skilled people.
The time estimate is based on the time it took to get RPM Fusion up and running.
Kevin Kofler
On Mon, Dec 22, 2008 at 11:12:58AM +0100, Kevin Kofler wrote:
Emmanuel Seyman wrote:
RPM Fusion decided to duplicate the Fedora infrastructure. This goes far above and beyond what you need to create a third-party repo.
Providing updates for all of Fedora actually requires MORE infrastructure than RPM Fusion. Just do the math.
Are you planning to maintain every package or just do security updates ?
On Mon, Dec 22, 2008 at 03:25:52PM +0100, Kevin Kofler wrote:
I'm really not planning anything, as the main driving force behind that effort is leaving Fedora (and I think the way his proposals were met is certainly part of the reason).
Only a part. It was certainly what made me really think whether fedora was really the place for me or not (it was not the first time, the first time was when static libs were banned). But I decided not to take this event to seriously, since I was personally and emotionally implicated it could have lead to a hasted decision. In the end I think that the ConsoleKit issue was more determining.
It is clear that it was determining, however, on the part about me doing noise without any long-term good for fedora.
I am still doing it, to avoid misinterpretations of history and other doing the same mistakes than me :-/
-- Pat
On Mon, Dec 22, 2008 at 10:55:57AM +0100, Kevin Kofler wrote:
updates and you can't find a linux related site to host your stuff initially you are doing something wrong or don't have enough interested skilled people.
The time estimate is based on the time it took to get RPM Fusion up and running.
Which was a large project based upon merging existing large projects and done for the first time. It has complex dependancies and politics.
Thats a bit like saying "Well concorde was hard so my paper aeroplane will take five years to fold"
I've been in the Free Software world for a fair number of years and I will say this - there are the people who say it is too hard/costs too much/can't be done and there are the people who just do it anyway. Do you think Linux would exist if Linus had started from a costing analysis for MS Windows or 4BSD ?
Just do it, the rest will fall into place if there is any interest.
Alan
On Mon, 2008-12-22 at 07:06 -0500, Alan Cox wrote:
On Mon, Dec 22, 2008 at 10:55:57AM +0100, Kevin Kofler wrote:
updates and you can't find a linux related site to host your stuff initially you are doing something wrong or don't have enough interested skilled people.
The time estimate is based on the time it took to get RPM Fusion up and running.
Which was a large project based upon merging existing large projects and done for the first time. It has complex dependancies and politics.
Thats a bit like saying "Well concorde was hard so my paper aeroplane will take five years to fold"
Wrong, it's like saying "there are easy and effective ways and there are less effective ways to achieve something".
I've been in the Free Software world for a fair number of years and I will say this - there are the people who say it is too hard/costs too much/can't be done and there are the people who just do it anyway. Do you think Linux would exist if Linus had started from a costing analysis for MS Windows or 4BSD ?
Just do it, the rest will fall into place if there is any interest.
Right, implementing a fork is the last resort, when an opensource project's leadership doesn't want listen.
Other options would exist if there was willingness amongst Fedora's sponsors and amongst Fedora's leadership - Both apparently do not exist.
Ralf
* Ralf Corsepius [22/12/2008 13:51] :
Right, implementing a fork is the last resort, when an opensource project's leadership doesn't want listen.
That's not true.
We've discussed this idea several times and, when people are told that they need to show there's a group of contributors to this project before infrastructure is dedicated to it, they don't fork the updates, they start whining and making up a whole bunch of excuses to justify not doing the work.
Emmanuel
On Mon, 2008-12-22 at 14:28 +0100, Emmanuel Seyman wrote:
- Ralf Corsepius [22/12/2008 13:51] :
Right, implementing a fork is the last resort, when an opensource project's leadership doesn't want listen.
That's not true.
We've discussed this idea several times and, when people are told that they need to show there's a group of contributors to this project before infrastructure is dedicated to it, they don't fork the updates, they start whining and making up a whole bunch of excuses to justify not doing the work.
We are turning in circles - It's a hen and egg problem.
FESCo brushes off volunteers, the @RHs (here A.C) gun-down any volunteers, ... what do you expect prospective volunteers to think?
Patrice already turned away from Fedora, I for one have significantly cut down my involvement into Fedora and am considering to further cut it down.
Ralf
* Ralf Corsepius [22/12/2008 14:56] :
We are turning in circles - It's a hen and egg problem.
Agreed. This is one of the reasons I'm getting very annoyed with the people making this proposal.
FESCo brushes off volunteers, the @RHs (here A.C) gun-down any volunteers, ... what do you expect prospective volunteers to think?
I expect them to setup a third-party repo and start publishing updates. Do you seriously think that, were I in their shoes, I would allow anyone or anything to stop me from doing so ?
Emmanuel
On Mon, 2008-12-22 at 15:04 +0100, Emmanuel Seyman wrote:
- Ralf Corsepius [22/12/2008 14:56] :
We are turning in circles - It's a hen and egg problem.
Agreed. This is one of the reasons I'm getting very annoyed with the people making this proposal.
FESCo brushes off volunteers, the @RHs (here A.C) gun-down any volunteers, ... what do you expect prospective volunteers to think?
I expect them to setup a third-party repo and start publishing updates.
Well, one of the Fedora prime objectives had been to unite the 3rd party repos, not to push around people to implement new ones.
Do you seriously think that, were I in their shoes, I would allow anyone or anything to stop me from doing so ?
... "The Spirits that they called" ...
Ralf
Ralf Corsepius wrote:
We are turning in circles - It's a hen and egg problem.
Agreed. This is one of the reasons I'm getting very annoyed with the people making this proposal.
FESCo brushes off volunteers, the @RHs (here A.C) gun-down any volunteers, ... what do you expect prospective volunteers to think?
I expect them to setup a third-party repo and start publishing updates.
Well, one of the Fedora prime objectives had been to unite the 3rd party repos, not to push around people to implement new ones.
Talk about things going in circles... There was a pre-fedora time when freshrpms had Red Hat updates available via apt-get - and it was the handiest way to get them.
Ralf Corsepius rc040203@freenet.de wrote:
On Mon, 2008-12-22 at 14:28 +0100, Emmanuel Seyman wrote:
- Ralf Corsepius [22/12/2008 13:51] :
Right, implementing a fork is the last resort, when an opensource project's leadership doesn't want listen.
That's not true.
We've discussed this idea several times and, when people are told that they need to show there's a group of contributors to this project before infrastructure is dedicated to it, they don't fork the updates, they start whining and making up a whole bunch of excuses to justify not doing the work.
We are turning in circles - It's a hen and egg problem.
No...
FESCo brushes off volunteers,
Haven't seen such.
the @RHs (here A.C) gun-down any
volunteers,
What I just saw was an _encouragement_ to go and just do it. That is not "gun down".
... what do you expect prospective volunteers to think?
That whining gets you nowhere fast. If you want to change something, ask. If the answers you get don't convince you, find like-minded people and go ahead and try it out. It doesn't need to be a full-fledged <whatever> at first, just a prototype. If it (even modestly) succeeds, you have /very/ strong arguments for the next round of discussions. If they still don't want to listen, you can go ahead and fork (that's the beauty of really open source!). By then you will have the momentum and experience to do so behind you.
Patrice already turned away from Fedora, I for one have significantly cut down my involvement into Fedora and am considering to further cut it down.
Sorry to hear that.
On Mon, 2008-12-22 at 15:42 -0300, Horst H. von Brand wrote:
Ralf Corsepius rc040203@freenet.de wrote:
On Mon, 2008-12-22 at 14:28 +0100, Emmanuel Seyman wrote:
- Ralf Corsepius [22/12/2008 13:51] :
Right, implementing a fork is the last resort, when an opensource project's leadership doesn't want listen.
That's not true.
We've discussed this idea several times and, when people are told that they need to show there's a group of contributors to this project before infrastructure is dedicated to it, they don't fork the updates, they start whining and making up a whole bunch of excuses to justify not doing the work.
We are turning in circles - It's a hen and egg problem.
No...
... sssst ... bang ... a bullet ...
FESCo brushes off volunteers,
Haven't seen such.
the @RHs (here A.C) gun-down any
volunteers,
What I just saw was an _encouragement_ to go and just do it. That is not "gun down".
Well, to me these "just do it" read as "piss off, we (RH) are not willing to support any such proposal".
Patrice already turned away from Fedora, I for one have significantly cut down my involvement into Fedora and am considering to further cut it down.
Sorry to hear that.
Yes. And ... rest assured, this mail of yours, as well as a similar reply of yours in a preceding similar threat have further added to it.
Ralf
On Mon, Dec 22, 2008 at 02:28:28PM +0100, Emmanuel Seyman wrote:
We've discussed this idea several times and, when people are told that they need to show there's a group of contributors to this project before infrastructure is dedicated to it, they don't fork the updates, they start whining and making up a whole bunch of excuses to justify not doing the work.
At least Kevin Kofler, Ralf Corsépius, Orion Paplowski, Manuel Wolfshant and myself were interested. And we didn't want 'dedicated infrastructure' before doing anything, but an agreement that such a project had a future. Did you even read the proposal? https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EO...
-- Pat
* Patrice Dumas [22/12/2008 15:05] :
At least Kevin Kofler, Ralf Corsépius, Orion Paplowski, Manuel Wolfshant and myself were interested. And we didn't want 'dedicated infrastructure' before doing anything, but an agreement that such a project had a future. Did you even read the proposal?
Yes. I stopped reading after the first three bullet points when I realized they were demands for dedicated infrastructure.
Emmanuel
Emmanuel Seyman wrote:
- Patrice Dumas [22/12/2008 15:05] :
At least Kevin Kofler, Ralf Corsépius, Orion Paplowski, Manuel Wolfshant and myself were interested. And we didn't want 'dedicated infrastructure' before doing anything, but an agreement that such a project had a future. Did you even read the proposal?
Yes. I stopped reading after the first three bullet points when I realized they were demands for dedicated infrastructure.
Read again. From the infrastructure point of view, all that is needed is to NOT kill koji building for older branches 1 month after a new release is out.
* Manuel Wolfshant [22/12/2008 15:36] :
Read again. From the infrastructure point of view, all that is needed is to NOT kill koji building for older branches 1 month after a new release is out.
This is dedicated infrastructure, IMHO.
Not to mention that it won't open all acls to packagers, nor will it create a repo to which the packages are pushed.
Emmanuel
On Mon, Dec 22, 2008 at 03:39:42PM +0100, Emmanuel Seyman wrote:
This is dedicated infrastructure, IMHO.
Not to mention that it won't open all acls to packagers, nor will it create a repo to which the packages are pushed.
The idea was to find volunteers, and assess the bandwidth and storage costs. I am sure you can read up to the end: https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EO... it can only lead to a more interesting conversation.
-- Pat
Emmanuel Seyman wrote:
- Manuel Wolfshant [22/12/2008 15:36] :
Read again. From the infrastructure point of view, all that is needed is to NOT kill koji building for older branches 1 month after a new release is out.
This is dedicated infrastructure, IMHO.
Not to mention that it won't open all acls to packagers, nor will it create a repo to which the packages are pushed.
"Create" a repo? For a distribution that already exists?
Emmanuel Seyman wrote:
- Les Mikesell [22/12/2008 17:17] :
"Create" a repo? For a distribution that already exists?
Yup. You can't just take over the fedora-updates repo changing the conditions under which updates are released without informing the users.
OK, inform the users. But if they observed the guidelines they wouldn't be attempting any updates anyway, would they? And why start being concerned about users now?
* Les Mikesell [22/12/2008 17:48] :
OK, inform the users. But if they observed the guidelines they wouldn't be attempting any updates anyway, would they?
???
And why start being
concerned about users now?
Whatever happens, the packages done after official EOL will almost certaingly be of lesser quality than the ones pre-EOL. If you aren't satisfied with the latter, you won't be satisfied with the former.
Emmanuel
Emmanuel Seyman wrote:
- Les Mikesell [22/12/2008 17:48] :
OK, inform the users. But if they observed the guidelines they wouldn't be attempting any updates anyway, would they?
???
And why start being
concerned about users now?
Whatever happens, the packages done after official EOL will almost certaingly be of lesser quality than the ones pre-EOL. If you aren't satisfied with the latter, you won't be satisfied with the former.
Errr, what? The only updates that need to be made after EOL are to fix what was already wrong. If pre-EOL quality is so good, you won't need any additional updates.
Emmanuel Seyman wrote:
- Les Mikesell [22/12/2008 17:48] :
OK, inform the users. But if they observed the guidelines they wouldn't be attempting any updates anyway, would they?
???
The distro is EOL and gets no updates, so why would they attempt to update it?
Whatever happens, the packages done after official EOL will almost certaingly be of lesser quality than the ones pre-EOL.
So what? It's EOL, users still using it deserve whatever they get.
And I think pushing out security updates, even if they're completely untested, would still be better than no updates at all.
Kevin Kofler
On Mon, Dec 22, 2008 at 06:17:10PM +0100, Kevin Kofler wrote:
And I think pushing out security updates, even if they're completely untested, would still be better than no updates at all.
No because you create the illusion of security which is more dangerous than knowing a system is insecure - in the latter case people at least take appropriate precautions.
If you've tested the security side then yes it probably is better than no updates at all.
Alan
Alan Cox wrote:
On Mon, Dec 22, 2008 at 06:17:10PM +0100, Kevin Kofler wrote:
And I think pushing out security updates, even if they're completely untested, would still be better than no updates at all.
No because you create the illusion of security which is more dangerous than knowing a system is insecure - in the latter case people at least take appropriate precautions.
If you've tested the security side then yes it probably is better than no updates at all.
Can you really make an argument that ignoring a real, known vulnerability is always better than an attempt at a fix - especially in fedora where the pre-EOL updates don't get much testing either?
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
Les Mikesell wrote:
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
Fedora is most cases, is way ahead in versions and that strategy won't work much. You could borrow a few fixes like Fedora Legacy used to but that is a small number.
Rahul
Rahul Sundaram wrote:
Les Mikesell wrote:
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
Fedora is most cases, is way ahead in versions and that strategy won't work much. You could borrow a few fixes like Fedora Legacy used to but that is a small number.
It would only work in the versions where the code cycle continued into RHEL and would take some coordination even there, with the tradeoff that no duplicate work would ever need to be done on the development side and there would be no incompatible version jumps to cause trouble on the user side.
But, how many things have big security risks anyway? In most cases the ones to worry about are just the kernel, network daemons, and suid programs - mostly things with standardized interfaces so backing up a version or two shouldn't break anything.
On Mon, 2008-12-22 at 12:09 -0600, Les Mikesell wrote:
But, how many things have big security risks anyway? In most cases the ones to worry about are just the kernel, network daemons, and suid programs - mostly things with standardized interfaces so backing up a version or two shouldn't break anything.
The big ugly ones are browsers, or other network facing applications that could leak your private data. Those are also the ones that tend to vary wildly between RHEL and Fedora, and even different releases of Fedora.
Trying to do a ff update for F8 in 8 months time would be a real treat.
Jesse Keating wrote:
The big ugly ones are browsers, or other network facing applications that could leak your private data. Those are also the ones that tend to vary wildly between RHEL and Fedora, and even different releases of Fedora.
Trying to do a ff update for F8 in 8 months time would be a real treat.
Yes, that's one of several thousand reasons why it would be better to gracefully slide into a Centos or Centos-like update repo instead of duplicating the work to match it - and to not even consider it on releases like F8.
Jesse Keating wrote:
Trying to do a ff update for F8 in 8 months time would be a real treat.
I'm pretty sure Remi Collet _will_ be doing Firefox updates for F8 8 months from now, right now he's still building Firefox updates for FC4.
The secret there: just update it to the new version. Even RHEL 4 got updated to Firefox 3. How to handle apps which are built against firefox-devel? Remi just provides a firefox2 for those. It won't be ideal if Mozilla EOLs Firefox 2 and nobody volunteers to backport security fixes, but at least the browser can be updated. Alternatively, the apps could be rebuilt against xulrunner, backporting the F9 packages where necessary. It could even be decided on an app-by-app basis.
Now I think it's pretty pointless to provide updated Firefox builds for Fedora releases which get no other updates, but it does prove that it's possible.
Kevin Kofler
On Mon, 2008-12-22 at 22:35 +0100, Kevin Kofler wrote:
I'm pretty sure Remi Collet _will_ be doing Firefox updates for F8 8 months from now, right now he's still building Firefox updates for FC4.
The secret there: just update it to the new version. Even RHEL 4 got updated to Firefox 3. How to handle apps which are built against firefox-devel? Remi just provides a firefox2 for those. It won't be ideal if Mozilla EOLs Firefox 2 and nobody volunteers to backport security fixes, but at least the browser can be updated. Alternatively, the apps could be rebuilt against xulrunner, backporting the F9 packages where necessary. It could even be decided on an app-by-app basis.
Now I think it's pretty pointless to provide updated Firefox builds for Fedora releases which get no other updates, but it does prove that it's possible.
Will Remmi be building the 20 some odd other packages that will then break when gecko library path changes? What about the packages in 3rd party repos that also depend on a gecko library path? What if these packages don't work with the new gecko?
Les Mikesell wrote:
Rahul Sundaram wrote:
Les Mikesell wrote:
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
Fedora is most cases, is way ahead in versions and that strategy won't work much. You could borrow a few fixes like Fedora Legacy used to but that is a small number.
It would only work in the versions where the code cycle continued into RHEL and would take some coordination even there, with the tradeoff that no duplicate work would ever need to be done on the development side and there would be no incompatible version jumps to cause trouble on the user side.
RHEL mostly freezes on everything and backports fixes selectively with few version bumps in between. Fedora stays more close to upstream and rarely backports fixes. If a security issue affects the recent version of any component in Fedora, you just cannot borrow a fix from RHEL in most cases as a result.
But, how many things have big security risks anyway? In most cases the ones to worry about are just the kernel, network daemons, and suid programs - mostly things with standardized interfaces so backing up a version or two shouldn't break anything.
You aren't considering things like Firefox which often requires security updates. You cannot just go back a few revisions and just hope to not break anything. Doesn't work that way. You don't even have to be a developer to be aware of that. Any sys admin would be aware of how brittle things can be.
Rahul
Rahul
Rahul Sundaram wrote:
Fedora is most cases, is way ahead in versions and that strategy won't work much. You could borrow a few fixes like Fedora Legacy used to but that is a small number.
It would only work in the versions where the code cycle continued into RHEL and would take some coordination even there, with the tradeoff that no duplicate work would ever need to be done on the development side and there would be no incompatible version jumps to cause trouble on the user side.
RHEL mostly freezes on everything and backports fixes selectively with few version bumps in between. Fedora stays more close to upstream and rarely backports fixes. If a security issue affects the recent version of any component in Fedora, you just cannot borrow a fix from RHEL in most cases as a result.
Yes, you'd have to coordinate this once the RHEL cut happens. With the result being something actually useful instead of just another throwaway beta. Fedora could just branch their next version at that point to satisfy people wanting fresh meat every day.
But, how many things have big security risks anyway? In most cases the ones to worry about are just the kernel, network daemons, and suid programs - mostly things with standardized interfaces so backing up a version or two shouldn't break anything.
You aren't considering things like Firefox which often requires security updates. You cannot just go back a few revisions and just hope to not break anything. Doesn't work that way. You don't even have to be a developer to be aware of that. Any sys admin would be aware of how brittle things can be.
How is that a particular issue? Even RHEL jumped FF versions in an update, so whatever they do should be acceptable in fedora which doesn't seem to follow any particular policy regarding version stability.
Les Mikesell wrote:
Yes, you'd have to coordinate this once the RHEL cut happens. With the result being something actually useful instead of just another throwaway beta. Fedora could just branch their next version at that point to satisfy people wanting fresh meat every day.
Explain to me, how that would work. Would Fedora ever move to a new upstream version or stay with the same version that RHEL does? If it moves to a new upstream version, how would you ensure that RHEL security fixes apply on Fedora? Don't use throw away words and explain it clearly.
How is that a particular issue? Even RHEL jumped FF versions in an update, so whatever they do should be acceptable in fedora which doesn't seem to follow any particular policy regarding version stability.
Firefox was just an example. If you are not aware of how either side works, no point in discussing a comparison.
Rahul
Rahul Sundaram wrote:
Yes, you'd have to coordinate this once the RHEL cut happens. With the result being something actually useful instead of just another throwaway beta. Fedora could just branch their next version at that point to satisfy people wanting fresh meat every day.
Explain to me, how that would work. Would Fedora ever move to a new upstream version or stay with the same version that RHEL does?
The version where the RHEL cut happens would track whatever happens to RHEL to the point that the update repos could be repointed to Centos when it appears without breakage. If it doesn't satisfy fedora developers to build towards stability even through one version out of 3 or 4, fedora could just start it's next version early to absorb the new untested stuff.
If it moves to a new upstream version, how would you ensure that RHEL security fixes apply on Fedora? Don't use throw away words and explain it clearly.
People claim to have done upgrades from the earlier corresponding fedora->Centos versions, perhaps manually tweaking a dozen or so packages so yum could do the rest. If that can happen without any particular planning, I have to think it would be possible to plan it to work without tweaking.
How is that a particular issue? Even RHEL jumped FF versions in an update, so whatever they do should be acceptable in fedora which doesn't seem to follow any particular policy regarding version stability.
Firefox was just an example. If you are not aware of how either side works, no point in discussing a comparison.
Given the FF and OOo jumps in RHEL, I don't think there is a specific 'how' anymore. But the point is that whatever RHEL does, I wish the fedora release that spawned it would do the same, even if the intermediate releases continue to be throwaway betas and even if it causes an odd jump in the release timing. It would have to result in less work, less incompatibility, less fragmentation, and more usability all the way around.
Les Mikesell wrote:
The version where the RHEL cut happens would track whatever happens to RHEL to the point that the update repos could be repointed to Centos when it appears without breakage. If it doesn't satisfy fedora developers to build towards stability even through one version out of 3 or 4, fedora could just start it's next version early to absorb the new untested stuff.
If I understand correctly, your idea is to base a longer update cycle of Fedora only on versions that Red Hat itself bases Red Hat Enterprise Linux on. However which release it is going to be, isn't known in advance since RHEL release schedules aren't known in advance.
Even if it is, RHEL is not always a snapshot of some Fedora release. Sometimes it is earlier than a release. There is also the case of Fedora updates moving past RHEL like FC6 updates did.
RHEL also makes a number of configuration changes and there are dependency differences between them as a result. How do you account for all that differences in updates? Fedora includes about 5 times more software packages than RHEL. What about security updates for all those software that is in Fedora but not in RHEL ? That gap continues to increase as well since the Fedora repository continues to grow at a rapid rate while RHEL repository size don't grow that much.
But the point is that whatever RHEL does, I wish the fedora release that spawned it would do the same
What the advantage of cloning the same thing twice?
Rahul
On Tue, 2008-12-23 at 01:23 +0530, Rahul Sundaram wrote:
RHEL also makes a number of configuration changes and there are dependency differences between them as a result. How do you account for all that differences in updates? Fedora includes about 5 times more software packages than RHEL. What about security updates for all those software that is in Fedora but not in RHEL ? That gap continues to increase as well since the Fedora repository continues to grow at a rapid rate while RHEL repository size don't grow that much.
One such huge difference is the existence of mono or not. Fedora has mono, RHEL does not. Lots of things do link against mono in Fedora, or build mono subpackages, but don't in RHEL. That's a whole can of worms to get into when trying to do an update for something.
Jesse Keating wrote:
On Tue, 2008-12-23 at 01:23 +0530, Rahul Sundaram wrote:
RHEL also makes a number of configuration changes and there are dependency differences between them as a result. How do you account for all that differences in updates? Fedora includes about 5 times more software packages than RHEL. What about security updates for all those software that is in Fedora but not in RHEL ? That gap continues to increase as well since the Fedora repository continues to grow at a rapid rate while RHEL repository size don't grow that much.
One such huge difference is the existence of mono or not. Fedora has mono, RHEL does not.
Is that likely to continue to be the case for the next RHEL?
Lots of things do link against mono in Fedora, or build mono subpackages, but don't in RHEL. That's a whole can of worms to get into when trying to do an update for something.
I'd expect silverlight/moonlight to become something fairly essential within the life of the next enterprise release, especially if netflix streaming works on it.
On Mon, 2008-12-22 at 14:50 -0600, Les Mikesell wrote:
Is that likely to continue to be the case for the next RHEL?
Yes, as far as I've seen. Nothing has changed to lower the risk level of mono.
Lots of things do link against mono in Fedora, or build mono subpackages, but don't in RHEL. That's a whole can of worms to get into when trying to do an update for something.
I'd expect silverlight/moonlight to become something fairly essential within the life of the next enterprise release, especially if netflix streaming works on it.
Given that silverlight/moonlight isn't even permissible in Fedora, there is no way it'll wind up in RHEL.
Les Mikesell wrote:
I'd expect silverlight/moonlight to become something fairly essential within the life of the next enterprise release, especially if netflix streaming works on it.
Silverlight/Moonlight isn't any more likely to appear in Fedora than MP3 is. It's patent-encumbered, it cannot be included in Fedora.
Kevin Kofler
2008/12/22 Kevin Kofler kevin.kofler@chello.at
Les Mikesell wrote:
I'd expect silverlight/moonlight to become something fairly essential within the life of the next enterprise release, especially if netflix streaming works on it.
Silverlight/Moonlight isn't any more likely to appear in Fedora than MP3 is. It's patent-encumbered, it cannot be included in Fedora.
I'll appriciate a list of the patents you believe are being infringed upon on Moonlight.
On Mon, 2008-12-22 at 22:55 +0100, David Nielsen wrote:
I'll appriciate a list of the patents you believe are being infringed upon on Moonlight.
Ask Microsoft, as they're promising not to sue Novell or people who get moonlight from Novell over those patents.
http://www.groklaw.net/article.php?story=20080528133529454
Kevin Kofler wrote:
Les Mikesell wrote:
I'd expect silverlight/moonlight to become something fairly essential within the life of the next enterprise release, especially if netflix streaming works on it.
Silverlight/Moonlight isn't any more likely to appear in Fedora than MP3 is. It's patent-encumbered, it cannot be included in Fedora.
Fedora doesn't have to _include_ everything. It just needs to provide working interfaces for 3rd party applications.
Les Mikesell wrote:
Kevin Kofler wrote:
Les Mikesell wrote:
I'd expect silverlight/moonlight to become something fairly essential within the life of the next enterprise release, especially if netflix streaming works on it.
Silverlight/Moonlight isn't any more likely to appear in Fedora than MP3 is. It's patent-encumbered, it cannot be included in Fedora.
Fedora doesn't have to _include_ everything. It just needs to provide working interfaces for 3rd party applications.
You don't need "interfaces" in this case. Download and run it from a Novell site since that's the only "legally safe" option according to
http://www.groklaw.net/article.php?story=20080528133529454
"It only covers 'direct' recipients from Novell, not 'indirect', which would likely exclude those who receive it directly from anyone other than Novell unless that third party is an 'authorized reseller'."
Rahul
Rahul Sundaram wrote:
The version where the RHEL cut happens would track whatever happens to RHEL to the point that the update repos could be repointed to Centos when it appears without breakage. If it doesn't satisfy fedora developers to build towards stability even through one version out of 3 or 4, fedora could just start it's next version early to absorb the new untested stuff.
If I understand correctly, your idea is to base a longer update cycle of Fedora only on versions that Red Hat itself bases Red Hat Enterprise Linux on.
Yes, I think that is the only practical option since I don't foresee stability coming from fedora itself. And realistically this is going to happen on the end users' computers that need stability anyway whether it is a planned and easy update or a harder wipe/re-install/re-configure. The difference being that a wipe/reinstall is also going to be a time to re-evaluate whether you care enough about the disto's sysadmin tools (that aren't serving you well since you have to start over) to stay on the same track or whether you want to jump to a different system that might be less trouble to deal with.
However which release it is going to be, isn't known in advance since RHEL release schedules aren't known in advance.
Even if it is, RHEL is not always a snapshot of some Fedora release.
So far the surprises have been rare.
Sometimes it is earlier than a release. There is also the case of Fedora updates moving past RHEL like FC6 updates did.
That's something that could be fixed. How hard is it to not update something?
RHEL also makes a number of configuration changes and there are dependency differences between them as a result. How do you account for all that differences in updates? Fedora includes about 5 times more software packages than RHEL. What about security updates for all those software that is in Fedora but not in RHEL ? That gap continues to increase as well since the Fedora repository continues to grow at a rapid rate while RHEL repository size don't grow that much.
Aren't those mostly in EPEL? Or, since we are talking about the next version, aren't they expected to be in EPEL? Or should people not be using them when planning projects that will run on enterprise versions?
But the point is that whatever RHEL does, I wish the fedora release that spawned it would do the same
What the advantage of cloning the same thing twice?
There's no additional human effort in cloning. What's the point of having software licenses that permit re-use if in fact you don't reuse it once you get it right?
Les Mikesell wrote:
However which release it is going to be, isn't known in advance since RHEL release schedules aren't known in advance.
Even if it is, RHEL is not always a snapshot of some Fedora release.
So far the surprises have been rare.
That's not a real answer. Whether it is rare or not, is has occurred and you need to have a plan to deal with that.
Sometimes it is earlier than a release. There is also the case of Fedora updates moving past RHEL like FC6 updates did.
That's something that could be fixed. How hard is it to not update something?
Pretty hard actually. You can't stagnate a released distribution for obvious reasons. FC6 is released. It has to be updated to include security fixes, bug fixes ... RHEL 5 has branched off but it would take another six months (internal testing, alpha, beta, partner testing etc) or so even before it is released. Remember, nobody in the Fedora world know the exact schedule in advance so they can't plan for it.
RHEL also makes a number of configuration changes and there are dependency differences between them as a result. How do you account for all that differences in updates? Fedora includes about 5 times more software packages than RHEL. What about security updates for all those software that is in Fedora but not in RHEL ? That gap continues to increase as well since the Fedora repository continues to grow at a rapid rate while RHEL repository size don't grow that much.
Aren't those mostly in EPEL?
You have completely ignored the point of configuration and dependency differences which means you can't just use the same stream of updates from RHEL in Fedora as you think you can.
Fedora and EPEL package count don't match at all. Go ahead and compare.
Or, since we are talking about the next
version, aren't they expected to be in EPEL? Or should people not be using them when planning projects that will run on enterprise versions?
Fedora still has way more packages than RHEL + EPEL and since you have to find maintainers and the upstream versions might depend on newer versions of software only available in the latest Fedora (remember EPEL packages cannot conflict with what is available in base RHEL), some will not build for a earlier version available in RHEL and the problem gets progressively worse as more versions of Fedora get much ahead of RHEL.
But the point is that whatever RHEL does, I wish the fedora release that spawned it would do the same
What the advantage of cloning the same thing twice?
There's no additional human effort in cloning. What's the point of having software licenses that permit re-use if in fact you don't reuse it once you get it right?
That wasn't my question. My question is why not just use RHEL or CentOS if you just going to duplicate the same stream of updates for Fedora as well? It just seems busy work for no benefit.
Rahul
Rahul Sundaram wrote:
That wasn't my question. My question is why not just use RHEL or CentOS if you just going to duplicate the same stream of updates for Fedora as well? It just seems busy work for no benefit.
That's precisely what I want to end up doing, but without the disruptive need to re-install and figure out what all those differences you are describing as problems are. And I'd rather not wait until the Centos release to start planning local development. I suspect many others have a similar development cycle and need about as much time as fedora itself to arrive at something suitable for another long-term starting point.
So, the question is whether someone who understands all the internals can plan a clean transition path and do it once, or whether every end user that needs stability has to muddle through it separately.
Rahul Sundaram wrote:
That wasn't my question. My question is why not just use RHEL or CentOS if you just going to duplicate the same stream of updates for Fedora as well? It just seems busy work for no benefit.
Les's idea is to be able to start with say (past example) FC2, then go to FC3, FC4 and from there to CentOS 4, effectively starting with newer software and gradually moving to the next CentOS release rather than being stuck with (at the time) CentOS 3.
Now I don't think that idea is implementable in practice, at least not without major changes to how both RHEL and Fedora are developed which I don't think are ever going to happen. But it's the idea and I think Les described it pretty clearly. I just disagree with it.
Kevin Kofler
Kevin Kofler wrote:
Now I don't think that idea is implementable in practice, at least not without major changes to how both RHEL and Fedora are developed which I don't think are ever going to happen. But it's the idea and I think Les described it pretty clearly. I just disagree with it.
Right. Now I understand it better. A transition in between Fedora and EL, in a cycle. I don't think it is workable either. If RHEL was a strict subset of Fedora (the exact same binaries), even for a release, maybe. Currently it isn't and probably isn't feasible either considering how the development model works and the community (of contributors) in Fedora.
Rahul
Kevin Kofler wrote:
Now I don't think that idea is implementable in practice, at least not without major changes to how both RHEL and Fedora are developed which I don't think are ever going to happen. But it's the idea and I think Les described it pretty clearly. I just disagree with it.
What is your optimal plan for someone to have local applications prepared and ready to take advantages of all the new developments in RHEL6 the day it is released?
The strategy I'm talking about is pretty much the way things worked before the RHEL/fedora split where RH X.0 and X.1 were equivalent to fedora versions with X.2 aging to stability, bringing with it the involvement of the community that worked through the development problems and tested their applications against the changes as they were made.
Les Mikesell wrote:
Kevin Kofler wrote:
Now I don't think that idea is implementable in practice, at least not without major changes to how both RHEL and Fedora are developed which I don't think are ever going to happen. But it's the idea and I think Les described it pretty clearly. I just disagree with it.
What is your optimal plan for someone to have local applications prepared and ready to take advantages of all the new developments in RHEL6 the day it is released?
This is really offtopic for this list and you should take it to a RHEL list instead but many do participate in Fedora and move on to RHEL beta releases and then to the GA release. Take up further questions on EL to EL specific mailing lists. Thanks.
Rahul
Rahul Sundaram wrote:
What is your optimal plan for someone to have local applications prepared and ready to take advantages of all the new developments in RHEL6 the day it is released?
This is really offtopic for this list and you should take it to a RHEL list instead but many do participate in Fedora and move on to RHEL beta releases and then to the GA release.
It is only offtopic if fedora is never intended to be used by people planning to move their work to RHEL and clones when the corresponding release appears. If that is a planned use case, then the discussion belongs here.
Take up further questions on EL to EL specific mailing lists. Thanks.
That doesn't make any sense. How can EL know how/why to deal with fedora, or know anything about transitioning to a version that doesn't exist yet?
Les Mikesell wrote:
Rahul Sundaram wrote:
What is your optimal plan for someone to have local applications prepared and ready to take advantages of all the new developments in RHEL6 the day it is released?
This is really offtopic for this list and you should take it to a RHEL list instead but many do participate in Fedora and move on to RHEL beta releases and then to the GA release.
It is only offtopic if fedora is never intended to be used by people planning to move their work to RHEL and clones when the corresponding release appears. If that is a planned use case, then the discussion belongs here.
No. It doesn't. This is a Fedora specific development list.
Take up further questions on EL to EL specific mailing lists. Thanks.
That doesn't make any sense. How can EL know how/why to deal with fedora, or know anything about transitioning to a version that doesn't exist yet?
You have subtly now changed your question but it is still offtopic in a Fedora development mailing list. Anyway your question has been answered by myself and Jesse Keating already. So no more EL specific questions here. Take it elsewhere.
Rahul
Les Mikesell lesmikesell@gmail.com wrote:
Rahul Sundaram wrote:
What is your optimal plan for someone to have local applications prepared and ready to take advantages of all the new developments in RHEL6 the day it is released?
This is really offtopic for this list and you should take it to a RHEL list instead but many do participate in Fedora and move on to RHEL beta releases and then to the GA release.
It is only offtopic if fedora is never intended to be used by people planning to move their work to RHEL and clones when the corresponding release appears. If that is a planned use case, then the discussion belongs here.
"Move work" != "move all the distribution"
I've moved work from Fedora to CentOS, even from rawhide Fedora to next-to-last CentOS, no big problem really.
Moving our servers from Fedora to CentOS required reinstall from scratch, and porting some data from backups. Did take a lot of work, but was done once. Since we just updated the operating systems when we were ready for it (mostly had time to check it out, and do any required changes, and test).
If you need stability, go for RHEL or CentOS + EPEL. If you want a technology preview, go for Fedora (even rawhide). If you need both at the same time on the same machine...
Horst H. von Brand wrote:
It is only offtopic if fedora is never intended to be used by people planning to move their work to RHEL and clones when the corresponding release appears. If that is a planned use case, then the discussion belongs here.
"Move work" != "move all the distribution"
I've moved work from Fedora to CentOS, even from rawhide Fedora to next-to-last CentOS, no big problem really.
So you weren't actually using any of the features that differentiate fedora?
Moving our servers from Fedora to CentOS required reinstall from scratch, and porting some data from backups. Did take a lot of work, but was done once.
Once = once per user. A lot of work for every user.
If you need stability, go for RHEL or CentOS + EPEL. If you want a technology preview, go for Fedora (even rawhide). If you need both at the same time on the same machine...
Not both at the same time. A development cycle where the community input during development results in features that end up being usable.
On Mon, 2008-12-22 at 16:07 -0600, Les Mikesell wrote:
What is your optimal plan for someone to have local applications prepared and ready to take advantages of all the new developments in RHEL6 the day it is released?
The likely strategy for RHEL6 would be:
Participate and consume F10, F11, and F12
Participate and consume RHEL6 Alphas and Betas (which may fall somewhere between F11 and F12)
Be ready to go when RHEL6 arrives. Basically once Alphas of RHEL start showing up, jump off the Fedora train and get on the RHEL train.
Les Mikesell lesmikesell@gmail.com wrote:
[...]
But, how many things have big security risks anyway? In most cases the ones to worry about are just the kernel, network daemons, and suid programs - mostly things with standardized interfaces so backing up a version or two shouldn't break anything.
Any program that could be run by a privileged account (or even just any local account) to process data from an untrusted source is a security risk.
I.e., most everything in Fedora.
Horst H. von Brand wrote:
Les Mikesell lesmikesell@gmail.com wrote:
[...]
But, how many things have big security risks anyway? In most cases the ones to worry about are just the kernel, network daemons, and suid programs - mostly things with standardized interfaces so backing up a version or two shouldn't break anything.
Any program that could be run by a privileged account (or even just any local account) to process data from an untrusted source is a security risk.
I.e., most everything in Fedora.
Are you suggesting that it is feasible to eliminate that risk?
On Tue, Dec 23, 2008 at 7:54 AM, Les Mikesell lesmikesell@gmail.com wrote:
Are you suggesting that it is feasible to eliminate that risk?
The outright elimination of risk is never the true goal of a mature risk management process.
Risk management is about defining what minimum acceptable levels of risk are and then implementing a mix of engineering and policy solutions which bring the risk inline with that acceptable level. Sometimes that acceptable risk is zero, sometimes its not. But you never assume at the beginning.
-jef
On Mon, 2008-12-22 at 11:39 -0600, Les Mikesell wrote:
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
That would often mean going backwards in version and features.
Les Mikesell wrote:
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
We already explained dozens of times why that can't work, why do you have to bring it up again and again? All you're going to get is more reasons why it can't work, e.g. Jesse Keating's answers. The major changes to both RHEL and Fedora which you're asking for are never going to happen.
Kevin Kofler
Kevin Kofler wrote:
Les Mikesell wrote:
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
We already explained dozens of times why that can't work, why do you have to bring it up again and again? All you're going to get is more reasons why it can't work, e.g. Jesse Keating's answers. The major changes to both RHEL and Fedora which you're asking for are never going to happen.
I bring it up again because it is the only hope I have of fedora being something that I'd have any use to run. If it isn't clearly the track towards the next RHEL/Centos, what's the point?
Les Mikesell wrote:
Kevin Kofler wrote:
Les Mikesell wrote:
Personally, I think the correct approach is to replace such things with a rebuilt RHEL version where the fix will actually have some QA before dropping into users' laps, but...
We already explained dozens of times why that can't work, why do you have to bring it up again and again? All you're going to get is more reasons why it can't work, e.g. Jesse Keating's answers. The major changes to both RHEL and Fedora which you're asking for are never going to happen.
I bring it up again because it is the only hope I have of fedora being something that I'd have any use to run. If it isn't clearly the track towards the next RHEL/Centos, what's the point?
People have pretty patient with you. It isn't that hard to realize that different people have different requirements. It is just easier to accept that, Fedora isn't suitable for your requirements and it is indeed suitable for those many, who are already using it and contributing to it for whatever reasons (many of which have nothing to EL) and move on. Your points are becoming very repetitive and doesn't accomplish anything new at all.
Rahul
Kevin Kofler kevin.kofler@chello.at wrote:
[...]
And I think pushing out security updates, even if they're completely untested, would still be better than no updates at all.
"Please don't make me move to a new set of packages" vs "dumping completely untested packages that perhaps fix a security problem are OK"... something sounds wrong here to me.
Also note that new developemt (and bug fixing, etc) in upstream projects happens at the development tips (which there is usually only one), finding and backporting security fixes only is a lot of work, and is /not/ trivial. I'd say the risk of breakage (or bad or missed fixes) is a lot higher than when just following upstream.
Le lundi 22 décembre 2008 à 15:21, Manuel Wolfshant a écrit :
Emmanuel Seyman wrote:
- Patrice Dumas [22/12/2008 15:05] :
At least Kevin Kofler, Ralf Corsépius, Orion Paplowski, Manuel Wolfshant and myself were interested. And we didn't want 'dedicated infrastructure' before doing anything, but an agreement that such a project had a future. Did you even read the proposal?
Yes. I stopped reading after the first three bullet points when I realized they were demands for dedicated infrastructure.
Read again. From the infrastructure point of view, all that is needed is to NOT kill koji building for older branches 1 month after a new release is out.
This is how I understood it.
Le lundi 22 décembre 2008 à 14:59, Patrice Dumas a écrit :
On Mon, Dec 22, 2008 at 02:28:28PM +0100, Emmanuel Seyman wrote:
We've discussed this idea several times and, when people are told that they need to show there's a group of contributors to this project before infrastructure is dedicated to it, they don't fork the updates, they start whining and making up a whole bunch of excuses to justify not doing the work.
At least Kevin Kofler, Ralf Corsépius, Orion Paplowski, Manuel Wolfshant and myself were interested. And we didn't want 'dedicated infrastructure' before doing anything, but an agreement that such a project had a future. Did you even read the proposal? https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_E OL
+1
I always submit my packages in all the branches I could.
Kevin Kofler kevin.kofler@chello.at wrote:
Alan Cox wrote:
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
But it's impossible to pull off without infrastructure, and setting up the infrastructure required for this project outside of Fedora requires months of work, and with the expected bandwidth requirements (think OO.o security updates), quite possibly also lots of money. That's why this project is doomed to fail without access to the official Fedora infrastructure, which is what was refused.
You do realize that said bandwidth would have to come out of Fedora's allotment, I presume.
On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
Of course, but doing it within fedora (even not officially) is what FESCo can accept or reject.
-- Pat
On Sun, Dec 21, 2008 at 06:30:57PM +0100, Patrice Dumas wrote:
On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
Of course, but doing it within fedora (even not officially) is what FESCo can accept or reject.
And why do you need to do it within Fedora - if the answer is "I can only do it by piggybacking on Fedora resources" then that sounds to me like you don't have the resources to do it without harming the existing Fedora by freeloading.
Alan
On Sun, Dec 21, 2008 at 12:44:50PM -0500, Alan Cox wrote:
And why do you need to do it within Fedora - if the answer is "I can only do it by piggybacking on Fedora resources" then that sounds to me like you don't have the resources to do it without harming the existing Fedora by freeloading.
Here was what I said in my proposal: https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EO...
This proposal does not want to divert resources from other uses in fedora. The idea is to profit from economies of scale and unused capacities (in the build system). Therefore infrastructure and releng teams should have a lot to say and the possibility to block if resources used are considered to be too high, especially if some work has to be done from those teams by people who are not volunteering to help that proposal to happen.
It is not about freeloading or anything like that, but using an already existing infrastructure. You seem to underestimate the costs of setting up an infrastructure, if you want to have an idea about that you could have a look at rpmfusion. I followed rpmfusion and it seems that it was quite a lot of work to have it done. Or you can have a look at EPEL which is still needing a lot of improvements in the infrastructure part.
-- Pat
On Sun, Dec 21, 2008 at 06:57:00PM +0100, Patrice Dumas wrote:
already existing infrastructure. You seem to underestimate the costs of setting up an infrastructure, if you want to have an idea about that you could have a look at rpmfusion. I followed rpmfusion and it seems that it was quite a lot of work to have it done. Or you can have a look at EPEL which is still needing a lot of improvements in the infrastructure part.
You seem to be trying to build a complete Fedora-alike infrastructure before you do anything. That to me seems crazy. What do you actually need - a corner on your own box to build rpms. A guest environment to test them and some disk space on an ftp site.
Yes you'll need to grow that - if you get lots of users/contributors, but you don't need to start that way. As it is so well put "Rome was not built in a day"
Alan
On Sun, Dec 21, 2008 at 02:23:00PM -0500, Alan Cox wrote:
You seem to be trying to build a complete Fedora-alike infrastructure before you do anything. That to me seems crazy. What do you actually need - a corner on your own box to build rpms. A guest environment to test them and some disk space on an ftp site.
Alan's quite right. I am hosting the MinGW RPMs temporarily on my own site (something like 700-800 MBs worth):
http://www.annexia.org/tmp/mingw/fedora-10/
This is of course no substitute for proper, reliable Fedora hosting and mirroring, which we'll get eventually once the packages are reviewed.
But I spend under $30 / month on this server, and there is no noticable load from the 565 people[1] synching their development machines to it.
Rich.
[1] "people" = distinct IPs making > 1 request for repomd.xml, so probably the real number of users is a bit less than this.
On Sun, Dec 21, 2008 at 08:05:05PM +0000, Richard W.M. Jones wrote:
[1] "people" = distinct IPs making > 1 request for repomd.xml, so probably the real number of users is a bit less than this.
I should add that I only count requests where the user-agent field indicates yum, so this doesn't include spiders/spammers/etc.
Rich.
Richard W.M. Jones wrote:
Alan's quite right. I am hosting the MinGW RPMs temporarily on my own site (something like 700-800 MBs worth):
But a single OO.o update alone is as large as all of your repo.
But I spend under $30 / month on this server, and there is no noticable load from the 565 people[1] synching their development machines to it.
And there would be a lot more than 565 people updating their old Fedora releases.
The infrastructure requirements for such a project would be several orders of magnitude higher than those for your MinGW repo or my CalcForge repo. There's no way a $30/month server would be able to provide the required bandwidth, maybe not even the required storage (but the bandwidth is proportional to size * download count, both of which are several orders of magnitude higher than for a small repository, so I expect the bandwidth to be the bigger issue, as it multiplies up, whereas the storage space is only dependent on the size of the packages).
Kevin Kofler
Kevin Kofler kevin.kofler@chello.at wrote:
Richard W.M. Jones wrote:
Alan's quite right. I am hosting the MinGW RPMs temporarily on my own site (something like 700-800 MBs worth):
But a single OO.o update alone is as large as all of your repo.
Right.
But I spend under $30 / month on this server, and there is no noticable load from the 565 people[1] synching their development machines to it.
And there would be a lot more than 565 people updating their old Fedora releases.
Says who?
The infrastructure requirements for such a project would be several orders of magnitude higher than those for your MinGW repo or my CalcForge repo. There's no way a $30/month server would be able to provide the required bandwidth, maybe not even the required storage (but the bandwidth is proportional to size * download count, both of which are several orders of magnitude higher than for a small repository, so I expect the bandwidth to be the bigger issue, as it multiplies up, whereas the storage space is only dependent on the size of the packages).
Sorry but "I can't make it work because it uses too much resources" doesn't jibe with "the resource requirements from Fedora infrastructure would be minimal"
Horst H. von Brand wrote:
Kevin Kofler kevin.kofler@chello.at wrote:
And there would be a lot more than 565 people updating their old Fedora releases.
Says who?
Common sense. Just look at the amount of times this idea comes up. Or at the amount of people still running F8.
Kevin Kofler
On Tue, Dec 23, 2008 at 9:26 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Common sense. Just look at the amount of times this idea comes up. Or at the amount of people still running F8.
I myself am shackled with using a legacy Fc5 system that I can't easily replace. Did I just hear you wince?
Would I love to be able to get updates for it... sure. Would I be helping to provide those updates. No. Do I think its reasonable to expect Fedora project to expend resources to provide those updates..no.
-jef
On Sun, Dec 21, 2008 at 02:23:00PM -0500, Alan Cox wrote:
You seem to be trying to build a complete Fedora-alike infrastructure before you do anything. That to me seems crazy. What do you actually need - a corner on your own box to build rpms. A guest environment to test them and some disk space on an ftp site.
Yes you'll need to grow that - if you get lots of users/contributors, but you don't need to start that way. As it is so well put "Rome was not built in a day"
Of course that can be done like that. But what was appealing in the use of fedora infrastructure after end of life was that it could be possible to avoid most costs associated with setting up an infrastructure of any size. The setup could have been done using already accumulated work (including community building) at litte additional cost.
It may be done otherwise, sure, it is free software, but I still think that it would be much less cost-effective.
Now FESCo/board can still veto that, the fact that it is cost-effective doesn't make it free. But saying that FESCo has no responsibility in this is wrong.
-- Pat
On Sun, Dec 21, 2008 at 09:21:10PM +0100, Patrice Dumas wrote:
infrastructure of any size. The setup could have been done using already accumulated work (including community building) at litte additional cost.
But cost and risk dumped on the community not the people proposing the idea.
It may be done otherwise, sure, it is free software, but I still think that it would be much less cost-effective.
Perhaps.. but the sooner you go do it the sooner it happens.
Alan
On Sun, Dec 21, 2008 at 03:33:12PM -0500, Alan Cox wrote:
But cost and risk dumped on the community not the people proposing the idea.
There was no risk, since it was explitcitly unofficial. Regarding the cost, the idea was that they could be assessed and the project reevaluated after the proposal was tested (I did paste the paragraph in a previous mail).
An underlying idea of mine was that it could help re-attract users and contributors or avoid that they leave, given that the balance in Fedora was much more on the innovative side. So, in my opinion there was some value for the Fedora project.
But this is certainly the weak part of such proposals, since instead many of the people leading fedora explicitely want such a project not to happen (irrespective of the costs) and the others are not in favor of it. And it is the real reason why the proposal was rejected, that's why I don't want to let think that there was a specific reason like cost or bug handling or size of the contributor base or whatever.
That being said I agree that the cost is still there and it is a valid reason.
It may be done otherwise, sure, it is free software, but I still think that it would be much less cost-effective.
Perhaps.. but the sooner you go do it the sooner it happens.
If the cost is higher, it may never happen.
-- Pat
On Sun, Dec 21, 2008 at 10:03:39PM +0100, Patrice Dumas wrote:
But cost and risk dumped on the community not the people proposing the idea.
There was no risk, since it was explitcitly unofficial.
There is always risk including the risk you mis-estimated the cost
It may be done otherwise, sure, it is free software, but I still think that it would be much less cost-effective.
Perhaps.. but the sooner you go do it the sooner it happens.
If the cost is higher, it may never happen.
Which any economist would I think take as fairly conclusive evidence there is insufficient demand. Especially as the "cost" is a corner of someones ftp site (probably free) [1], a bit of developers disk and machine time (basically free nowdays) and developers own time.
Alan [1] Seriously show me five people planning to contribute to this and I'm happy to sort out a corner in ftp.linux.org.uk.
Alan Cox wrote:
Alan [1] Seriously show me five people planning to contribute to this and I'm happy to sort out a corner in ftp.linux.org.uk.
I am not much of a programmer any more (hence, without help from someone more experienced, backporting would probably be out of my league ) but I would gladly contribute as a packaging monkey if fedora-legacy would be revived. I still have RH 7.2, RH 7.2, FC1, FC2, FC6 and FC7 in production, so from time to time I have to recompile stuff anyway. Not to mention that very often I compile stuff from Fedora for Centos 4 and 5
Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Alan Cox wrote:
Alan [1] Seriously show me five people planning to contribute to this and I'm happy to sort out a corner in ftp.linux.org.uk.
I am not much of a programmer any more (hence, without help from someone more experienced, backporting would probably be out of my league ) but I would gladly contribute as a packaging monkey if fedora-legacy would be revived. I still have RH 7.2, RH 7.2, FC1, FC2, FC6 and FC7 in production, so from time to time I have to recompile stuff anyway.
Why not move on?
Not to mention that very often I compile stuff from Fedora for Centos 4 and 5
Integrate in EPEL?
On 12/23/2008 06:36 PM, Horst H. von Brand wrote:
Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Alan Cox wrote:
Alan [1] Seriously show me five people planning to contribute to this and I'm happy to sort out a corner in ftp.linux.org.uk.
I am not much of a programmer any more (hence, without help from someone more experienced, backporting would probably be out of my league ) but I would gladly contribute as a packaging monkey if fedora-legacy would be revived. I still have RH 7.2, RH 7.2, FC1, FC2, FC6 and FC7 in production, so from time to time I have to recompile stuff anyway.
Why not move on?
Because they do their job just fine as they are. For instance my workstation in F7 behaves much better that a F-10 which fails to see it's DNS servers and 2-3 times a month I regret that I have installed F9 instead of Centos 5 on the workstation used by my 70+ yrs old mother
Not to mention that very often I compile stuff from Fedora for Centos 4 and 5
Integrate in EPEL?
When it makes sense and I have the time, I suggest the respective package maintainers to do that. Or I volunteer for co-maint. for EPEL branches. But sometimes my packages cannot be integrated in EPEL. Generally speaking, I try to verify if any package I review is an EPEL candidate and/ or suggest the fixes needed (if / when I know how to, as I might have said in a previous life I was a programmer but a) I've never been a very good programmer b) I was using Borland C++ c) this happened a very long time ago).But I have compiled nedit for instance way before it landed in EPEL, it's one of the favorite editors in the company I work for and EL-5 missing it was a reason for many cryings and tears. Anyway, I do not think that this thread should focus on EPEL, The problem from my point of view is "
Fedora 8 will be end-of-life and no further updates, including security updates, will be released at that time, and new builds will not be allowed in the buildsystem"
I fail to see why no update at all is a better policy than "we update what we can when we can, but we no longer officially support this vesion of the distribution. Please understand that you are in uncharted territory, we'll try to help as much as we can but you might be better by simply upgrading to a newer distro."
On 12/23/08, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
I fail to see why no update at all is a better policy than "we update what we can when we can, but we no longer officially support this vesion of the distribution. Please understand that you are in uncharted territory, we'll try to help as much as we can but you might be better by simply upgrading to a newer distro."
Correct, you "fail to see". Take a broader, more open-minded, look at what defines "we", and "what", and "when" in the above statement. I'd really rather find "Upgrade to the latest", as opposed to finding "Here's our wishy-washy state, hope for the best".
jerry
Manuel Wolfshant wrote:
I fail to see why no update at all is a better policy than "we update what we can when we can, but we no longer officially support this vesion of the distribution. Please understand that you are in uncharted territory, we'll try to help as much as we can but you might be better by simply upgrading to a newer distro."
+1
Kevin Kofler
Le mercredi 24 décembre 2008 à 09:48, Kevin Kofler a écrit :
Manuel Wolfshant wrote:
I fail to see why no update at all is a better policy than "we update what we can when we can, but we no longer officially support this vesion of the distribution. Please understand that you are in uncharted territory, we'll try to help as much as we can but you might be better by simply upgrading to a newer distro."
+1
Kevin Kofler
+1
Alain
* Manuel Wolfshant [24/12/2008 08:56] :
I fail to see why no update at all is a better policy than "we update what we can when we can, but we no longer officially support this vesion of the distribution. Please understand that you are in uncharted territory, we'll try to help as much as we can but you might be better by simply upgrading to a newer distro."
The problem isn't so much deciding on a policy as it is making that policy known to the users and allowing them to opt-in/opt-out to whatever you're proposing.
Emmanuel
On Wed, Dec 24, 2008 at 06:13:57AM +0200, Manuel Wolfshant wrote:
But sometimes my packages cannot be integrated in EPEL.
This is the point. It's lots of extra, unsexy work to backport newer packages, updates and security fixes to EPEL. That's what people pay good money to Red Hat to do to get RHEL (or use CentOS). Any 'Fedora Legacy II' project will have to do the same thing, at the very least with security patches.
Rich.
Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
[...]
I fail to see why no update at all is a better policy than "we update what we can when we can, but we no longer officially support this vesion of the distribution. Please understand that you are in uncharted territory, we'll try to help as much as we can but you might be better by simply upgrading to a newer distro."
Because upgrading gives you some assurance that the stuff you depend on _will_ be maintained. "Perhaps glaring problems will be fixed. Probably not. If your box gets broken into, tough luck" is _not_ what I would like people to take home as "Linux experience". Because "But I got it from Fedora's site! They even shipped an update last month!!" /makes/ Fedora (at least morally) liable if it goes bad.
Besides, keeping old stuff around for ages /is/ a resource commitment. For no good reason, even.
Alan Cox wrote:
On Sun, Dec 21, 2008 at 06:30:57PM +0100, Patrice Dumas wrote:
On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
Of course, but doing it within fedora (even not officially) is what FESCo can accept or reject.
And why do you need to do it within Fedora - if the answer is "I can only do it by piggybacking on Fedora resources" then that sounds to me like you don't have the resources to do it without harming the existing Fedora by freeloading.
And what is your guess on the time it would take for a lawsuit threat if someone actually did provide a Fedora-labeled distribution that didn't meet Fedora policies?
On Sun, Dec 21, 2008 at 01:08:31PM -0600, Les Mikesell wrote:
And what is your guess on the time it would take for a lawsuit threat if someone actually did provide a Fedora-labeled distribution that didn't meet Fedora policies?
I don't see the relevance of that question. If it doesn't follow Fedora policy it isn't Fedora. It's another Fedora based distro with a longer lifetime.
Nothing to do with whether it can be done, and if it works well then maybe it'll later become an official bit of Fedora.
The other way I can read you email is "I want to use the Fedora name for my own purposes and do as I like so screw you all", which I hope is not the intent you want to convey.
Alan
Alan Cox wrote:
On Sun, Dec 21, 2008 at 01:08:31PM -0600, Les Mikesell wrote:
And what is your guess on the time it would take for a lawsuit threat if someone actually did provide a Fedora-labeled distribution that didn't meet Fedora policies?
I don't see the relevance of that question. If it doesn't follow Fedora policy it isn't Fedora. It's another Fedora based distro with a longer lifetime.
Nothing to do with whether it can be done, and if it works well then maybe it'll later become an official bit of Fedora.
The other way I can read you email is "I want to use the Fedora name for my own purposes and do as I like so screw you all", which I hope is not the intent you want to convey.
It's more like "Fedora would have to change before I would find it useful for any purpose", which I guess is only slightly different. Or at least any purpose other than a preview of what the next RHEL might contain and even that hasn't looked too promising lately.
But as far as making usably stable versions, there are a couple of approaches that would avoid wasting a lot of resources. One is to plan a smooth transition into the next Centos via yum update to end up with a real long term supported system without duplicating any work on backported updates. Another which isn't really a long-term approach but could produce usably-stable versions that overlapped a bit would be to stop introducing new features in updates in one release by or before the beta of the next release and focus only on stability from that point to end of life. Even if EOL is not extended you'd have a version that you could run until the next version reached that point - and people who want new features can jump to the next release instead.
* Les Mikesell [21/12/2008 22:03] :
One is to plan
a smooth transition into the next Centos via yum update to end up with a real long term supported system without duplicating any work on backported updates.
This, to me, not only conveys the intent : "I'm going to drain Fedora ressources away from Fedora's mission" but also the intent "I'm going to use thoses ressources to promote another distribution".
Emmanuel
Emmanuel Seyman wrote:
- Les Mikesell [21/12/2008 22:03] :
One is to plan
a smooth transition into the next Centos via yum update to end up with a real long term supported system without duplicating any work on backported updates.
This, to me, not only conveys the intent : "I'm going to drain Fedora ressources away from Fedora's mission" but also the intent "I'm going to use thoses ressources to promote another distribution".
Better said as "any reduction in the fragmentation into incompatible flavors is a win for everyone involved with unix-like operating systems". Or, "any effort to separately maintain fragmented distributions is a wasted effort".
* Les Mikesell [22/12/2008 09:52] :
Better said as "any reduction in the fragmentation into incompatible flavors is a win for everyone involved with unix-like operating systems". Or, "any effort to separately maintain fragmented distributions is a wasted effort".
The cure for fragmentation is to keep as close to upstream as possible and encourage other distributions to do the same. I fail to see how planning "a smooth transition into the next Centos" has anything to do with it.
Emmanuel
Emmanuel Seyman wrote:
- Les Mikesell [22/12/2008 09:52] :
Better said as "any reduction in the fragmentation into incompatible flavors is a win for everyone involved with unix-like operating systems". Or, "any effort to separately maintain fragmented distributions is a wasted effort".
The cure for fragmentation is to keep as close to upstream as possible and encourage other distributions to do the same.
No it isn't. Upstream projects make wild and crazy changes every day that I want no part of until they've stabilized and are suitable to use for years unchanged. The cure for fragmentation is to pick some standard interfaces and stick to them so the code on each side can be optimized separately without breaking the other.
I fail to see how planning "a smooth transition into the next Centos" has anything to do with it.
The 'smooth transition' is to avoid breaking the user's machine or forcing a re-install. Maybe that's a foreign concept to fedora, but for me, the point of running any new code is to get it to the point where it will continue to serve you for years. That is, the system should work for you instead of you working to continually change it to something that isn't quite reliable yet.
If you don't introduce any incompatibilities between the RHEL cut and that fedora version's EOL, it should be feasible to do a final 'yum update' that slides the stable code into place along with switching the update repositories. The machine then continues to work with stable code and update support for the next 7 years with no additional burden on fedora resources and the user continues to be happy with his choice to start with fedora. Historically this would have been feasible with minor changes from FC1->Centos3, FC3->Centos4, FC6->Centos5. If planned ahead of time it should be even easier.
If you don't like the Centos 'brand' switch - or don't understand why the code follows a natural path this way, fedora could do it's own RHEL rebranding. Or maybe Red Hat could wake up and realize that a free distro of their own would be a return to what made their name in the first place. In any case there should be no need to duplicate the work of backporting security and bug fixes into otherwise stable code that is free for anyone to use.
* Les Mikesell [22/12/2008 15:11] :
No it isn't. Upstream projects make wild and crazy changes every day that I want no part of until they've stabilized and are suitable to use for years unchanged. The cure for fragmentation is to pick some standard interfaces and stick to them so the code on each side can be optimized separately without breaking the other.
??? This is the LSB specification.
Emmanuel
Emmanuel Seyman wrote:
- Les Mikesell [22/12/2008 15:11] :
No it isn't. Upstream projects make wild and crazy changes every day that I want no part of until they've stabilized and are suitable to use for years unchanged. The cure for fragmentation is to pick some standard interfaces and stick to them so the code on each side can be optimized separately without breaking the other.
??? This is the LSB specification.
Except it isn't really useful either in what it specifies or how everyone implements it. Can you, for example, NFS mount your /home from various OS's and run their apps, knowing that one of them won't make incompatible and irreversible changes to the formats of the dotfiles stored there, or even count on your python scripts to work across them?
On the other hand, there is a direct code lineage for most packages from a fedora cycle through RHEL and thus Centos, so unless someone explicitly breaks it there is no reason everything can't just keep working.
Les Mikesell wrote:
backported updates. Another which isn't really a long-term approach but could produce usably-stable versions that overlapped a bit would be to stop introducing new features in updates in one release by or before the beta of the next release and focus only on stability from that point to end of life. Even if EOL is not extended you'd have a version that you could run until the next version reached that point - and people who want new features can jump to the next release instead.
No, we can't jump to the next release if it's only in beta. Just because we want new features doesn't mean we want a beta distro! The earliest a "stabilization" like that would be acceptable would be 1 month (time to upgrade) after the next release is out.
And I don't see how the current system is not "usably-stable". Fedora just works.
Kevin Kofler
Kevin Kofler wrote:
Les Mikesell wrote:
backported updates. Another which isn't really a long-term approach but could produce usably-stable versions that overlapped a bit would be to stop introducing new features in updates in one release by or before the beta of the next release and focus only on stability from that point to end of life. Even if EOL is not extended you'd have a version that you could run until the next version reached that point - and people who want new features can jump to the next release instead.
No, we can't jump to the next release if it's only in beta. Just because we want new features doesn't mean we want a beta distro!
As long as you are adding new features, it is always the equivalent of beta - pretty much by definition.
The earliest a "stabilization" like that would be acceptable would be 1 month (time to upgrade) after the next release is out.
OK, so now you are down to a 5 month stable life. Still better than none like it has now.
And I don't see how the current system is not "usably-stable". Fedora just works.
Except when it doesn't. Would you bet your life on it working correctly after every update? You'd have lost several times on my machines, including an update very near the end of FC6's life - a point where there was no reason at all to be making changes likely to break things. And I'm not using it again for anything that matters until I have some reason to think it won't be repeated.
Les Mikesell wrote:
As long as you are adding new features, it is always the equivalent of beta - pretty much by definition.
No it's not. Only features which are considered safe by their maintainers are added.
Except when it doesn't. Would you bet your life on it working correctly after every update? You'd have lost several times on my machines, including an update very near the end of FC6's life - a point where there was no reason at all to be making changes likely to break things.
If an update is broken, I just revert it with rpm -Uvh --oldpackage, problem solved. (This assumes you have the previous package still cached, but that's what keepcache=1 in yum.conf is for. I don't understand why that's not the default.) But this happens pretty rarely in my experience.
And what were you doing running FC6 very near the end of its life? You should have upgraded to F7 or F8 by then. :-) The updates for old releases get less testing because most packagers and most of the people running updates-testing have long since moved on to a newer one by then.
And I'm not using it again for anything that matters until I have some reason to think it won't be repeated.
I'm running Fedora on my machines (a desktop, a laptop and an old laptop which I don't really use anymore because the new one is way faster) just fine. I don't use any other OS.
Kevin Kofler
Kevin Kofler wrote:
Les Mikesell wrote:
As long as you are adding new features, it is always the equivalent of beta - pretty much by definition.
No it's not. Only features which are considered safe by their maintainers are added.
I don't think you understand the concept of alpha/beta phases. Alpha is when a developer 'thinks' something is ready. Beta continues until this has been proven correct. As far as I can tell, fedora updates _never_ reach the tested/proven phase and even if they did, any package set that has been tested together isn't repeatable on another machine because the repositories keep changing.
Except when it doesn't. Would you bet your life on it working correctly after every update? You'd have lost several times on my machines, including an update very near the end of FC6's life - a point where there was no reason at all to be making changes likely to break things.
If an update is broken, I just revert it with rpm -Uvh --oldpackage, problem solved. (This assumes you have the previous package still cached, but that's what keepcache=1 in yum.conf is for.
This was a kernel change, so the old one was there. But, you had to be at the machine when it booted to fix it. I wasn't - and don't want to be forced to be.
I don't understand why that's not the default.) But this happens pretty rarely in my experience.
Rare isn't good enough, and it relates to the 'beta' quality. If that had been tested on any similar machine before pushing the update it wouldn't have happened. I just don't see the point of every having to deal with crap like that on a machine where I have real work - ever. And I don't see the point of maintaining a test machine when the updates aren't repeatable and keep adding new untested content during a release life. There is no value in testing something that is just going to have new wild and crazy changes before you get any use out of the tested copy.
And what were you doing running FC6 very near the end of its life? You should have upgraded to F7 or F8 by then. :-)
I'm not completely insane. And the equivalent fedora versions that had previously been used for the RHEL cuts (FC1, FC3) had become fairly stable near their own end of life so I had at least some hope for FC6. Now even that is gone and I don't see a trend heading anywhere toward a stable version that would make a reasonable RHEL6 either.
The updates for old releases
get less testing because most packagers and most of the people running updates-testing have long since moved on to a newer one by then.
And I'm not using it again for anything that matters until I have some reason to think it won't be repeated.
I'm running Fedora on my machines (a desktop, a laptop and an old laptop which I don't really use anymore because the new one is way faster) just fine. I don't use any other OS.
Good luck with that. I hope you keep copies of your work on the spare machines. Or your work isn't important enough that downtime matters. Also, think about how much time you spend re-installing and grooming fedora. I used to think that if you only had to do something to a machine once a year it was a good thing. But, as soon as you manage more than a few hundred of them, that turns into having to deal with some problem every day and getting nothing else done.
Les Mikesell wrote:
I don't think you understand the concept of alpha/beta phases. Alpha is when a developer 'thinks' something is ready. Beta continues until this has been proven correct.
That's what updates-testing is for.
There is no value in testing something that is just going to have new wild and crazy changes before you get any use out of the tested copy.
You could keep a local mirror with the updates you're testing, then update the non-test machine(s) to those, not to the very latest. But I don't see that as being necessary at all.
And what were you doing running FC6 very near the end of its life? You should have upgraded to F7 or F8 by then. :-)
I'm not completely insane.
;-)
Upgrading is the sane thing to do when your distro is nearing EOL...
Now even that is gone and I don't see a trend heading anywhere toward a stable version that would make a reasonable RHEL6 either.
F10 is pretty stable, as is F9 with the current updates, the problems it had when it was released are all fixed now. Rumors are that RHEL6 will be based on F11, this should work out pretty well.
Good luck with that. I hope you keep copies of your work on the spare machines. Or your work isn't important enough that downtime matters.
I do keep backup copies of my work (I have 3 copies of most stuff: on my desktop, on my laptop and on a university machine or some other server), it's always a sane thing to do no matter what OS you run. But I never had Fedora destroy my data.
Also, think about how much time you spend re-installing and grooming fedora. I used to think that if you only had to do something to a machine once a year it was a good thing. But, as soon as you manage more than a few hundred of them, that turns into having to deal with some problem every day and getting nothing else done.
Don't worry, I'm not planning to buy 97 additional machines any time soon. ;-) I'm not adminning a large installation.
Kevin Kofler
Les Mikesell wrote:
works.
And I don't see how the current system is not "usably-stable". Fedora just
Except when it doesn't. Would you bet your life on it working correctly after every update? You'd have lost several times on my machines, including an update very near the end of FC6's life - a point where there was no reason at all to be making changes likely to break things. And I'm not using it again for anything that matters until I have some reason to think it won't be repeated.
You seem to expend a remarkable amount of energy on something you will "never use again for anything that matters".
Adam Huffman wrote:
And I don't see how the current system is not "usably-stable". Fedora just
Except when it doesn't. Would you bet your life on it working correctly after every update? You'd have lost several times on my machines, including an update very near the end of FC6's life - a point where there was no reason at all to be making changes likely to break things. And I'm not using it again for anything that matters until I have some reason to think it won't be repeated.
You seem to expend a remarkable amount of energy on something you will "never use again for anything that matters".
A lot of good engineering happens in fedora. Eventually it affects other distributions where it does matter. Unfortunately there seems to be an executive fiat keeping fedora itself from becoming usable in the way the RH development worked before fedora existed - back when people were attracted to Red Hat in the first place and the community that helped develop, test, and debug a release ended up with something that worked for some length of time at the end.
Les Mikesell wrote:
And what is your guess on the time it would take for a lawsuit threat if someone actually did provide a Fedora-labeled distribution that didn't meet Fedora policies?
His guess is irrelevant. Don't deliberately break policies and you don't have to worry about that.
Rahul
On Sun, Dec 21, 2008 at 8:44 AM, Alan Cox alan@redhat.com wrote:
On Sun, Dec 21, 2008 at 06:30:57PM +0100, Patrice Dumas wrote:
On Sun, Dec 21, 2008 at 12:14:38PM -0500, Alan Cox wrote:
FESCo has no power to make it work or not work. The GPL gave people all the rights they need to create a long term Fedora variant.
Of course, but doing it within fedora (even not officially) is what FESCo can accept or reject.
And why do you need to do it within Fedora - if the answer is "I can only do it by piggybacking on Fedora resources" then that sounds to me like you don't
You know what I find interesting, This particular idea wasn't in any of the candidate statements for any of the people running for FESCo. If this were really a problem with existing governance decision making I would have expected to see a candidate running for FESCo mention supporting this idea explicitly in their nomination wiki info. I don't remember seeing that.
-jef
On Sun, Dec 21, 2008 at 03:54:21PM -0900, Jeff Spaleta wrote:
Of course, but doing it within fedora (even not officially) is what FESCo can accept or reject.
And why do you need to do it within Fedora - if the answer is "I can only do it by piggybacking on Fedora resources" then that sounds to me like you don't
You know what I find interesting, This particular idea wasn't in any of the candidate statements for any of the people running for FESCo. If this were really a problem with existing governance decision making I would have expected to see a candidate running for FESCo mention supporting this idea explicitly in their nomination wiki info. I don't remember seeing that.
I don't know exactly who you are answering to, but as far as I can tell nobody said that there were 'a problem with existing governance decision making'. The keep infra open stuff was lead by me and Kevin Kofler, Ralf, and Oron was also supportive, but none of these people ran for FESCo.
And you could also interpret it the other way (I am not saying that it is my interpretation): there is a governance problem because nobody supporting this idea explicitly ran for FESCo.
-- Pat