People,
Date: Sun, 27 Jan 2013 15:18:40 -0500 From: "Eddie G. O'Connor Jr." eoconnor25@gmail.com To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: humble suggestion to Fedora developers Message-ID: 51058BA0.8020509@GMail.com Content-Type: text/plain; charset=UTF-8; format=flowed
On 01/23/2013 02:59 PM, James Freer wrote:
On Wed, Jan 23, 2013 at 7:34 PM, Joe Zeff joe@zeff.us wrote:
On 01/23/2013 06:53 AM, Reindl Harald wrote:
because first new anaconda was approved and integration all over the distribution started and after that damage was done people realized "hm new anaconda is not ready"
So what you're saying is, it was approved before it was ready. Judging from what else you wrote, the devs didn't realize it when they approved it. This suggests to me that approval came too early in the process, before proper testing was done and that important parts of the program hadn't been completed. If so, is there anything that can be done to prevent this from happening yet again?
I have the greatest respect for the developer's that put in considerable effort for each release. The problem with 6 month release cycle is too little time. I've used linux now for almost 6 years with Ubuntu and Fedora. Some distros use a two year release which is too long. One or two use an annual release which i think is about right... development and testing can fully take place. Why not consider an annual release which would give appropriate time for all to take place?
james
I would have to agree with you James, it might not be a bad idea for them to stretch their release time out a bit? I would have positives from all sides. First,....the developers would be able to REALLY put their apps and what-not through a GRUELING testing session, this way...when they say it works.....IT WORKS! Second,.....the public wouldn't find themselves scurrying to acquire the latest version, and slamming it onto their machines without knowing that things won't crash & burn un-necessarily......also it would give the public time to "adapt" and become comfortable with the latest release, instead of going into shock at the arrival of a new desktop environment...or new feature-sets that were not there before. I guess it's just a matter of someone (or a LOT of someone's) voicing their opinion loud enough to be heard by the higher-ups? I don't know that they would actually change things around like that....(it would be NICE!) but eventually they might get restless enough to completely flip thing around and have longer time frames between releases.
Maybe we should try out, say, a nine month cycle and if it doesn't suit - go back to six months? I am conscious though of the human tendency to put off things when there is more time to get them done . .
Regards,
Phil.
On Mon, 28 Jan 2013 10:55:24 +1100 Philip Rhoades phil@pricom.com.au wrote:
People,
Date: Sun, 27 Jan 2013 15:18:40 -0500 From: "Eddie G. O'Connor Jr." eoconnor25@gmail.com To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: humble suggestion to Fedora developers Message-ID: 51058BA0.8020509@GMail.com Content-Type: text/plain; charset=UTF-8; format=flowed
On 01/23/2013 02:59 PM, James Freer wrote:
On Wed, Jan 23, 2013 at 7:34 PM, Joe Zeff joe@zeff.us wrote:
On 01/23/2013 06:53 AM, Reindl Harald wrote:
because first new anaconda was approved and integration all over the distribution started and after that damage was done people realized "hm new anaconda is not ready"
So what you're saying is, it was approved before it was ready. Judging from what else you wrote, the devs didn't realize it when they approved it. This suggests to me that approval came too early in the process, before proper testing was done and that important parts of the program hadn't been completed. If so, is there anything that can be done to prevent this from happening yet again?
I have the greatest respect for the developer's that put in considerable effort for each release. The problem with 6 month release cycle is too little time. I've used linux now for almost 6 years with Ubuntu and Fedora. Some distros use a two year release which is too long. One or two use an annual release which i think is about right... development and testing can fully take place. Why not consider an annual release which would give appropriate time for all to take place?
james
I would have to agree with you James, it might not be a bad idea for them to stretch their release time out a bit? I would have positives from all sides. First,....the developers would be able to REALLY put their apps and what-not through a GRUELING testing session, this way...when they say it works.....IT WORKS! Second,.....the public wouldn't find themselves scurrying to acquire the latest version, and slamming it onto their machines without knowing that things won't crash & burn un-necessarily......also it would give the public time to "adapt" and become comfortable with the latest release, instead of going into shock at the arrival of a new desktop environment...or new feature-sets that were not there before. I guess it's just a matter of someone (or a LOT of someone's) voicing their opinion loud enough to be heard by the higher-ups? I don't know that they would actually change things around like that....(it would be NICE!) but eventually they might get restless enough to completely flip thing around and have longer time frames between releases.
Maybe we should try out, say, a nine month cycle and if it doesn't suit
- go back to six months? I am conscious though of the human tendency to
put off things when there is more time to get them done . .
But the rush to release will still be there, whether it is a 6- or 9- or 12-month cycle? At the point of release, inadequately-tested new features may still be a problem, no?
I think a more reliable approach is to have a rolling release model, with periodic snapshot RPMs in a cycle? The periodic snapshots could be benchmark-based, so no specific time schedule, rather than calendar-based?
Ranjan
____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
On 01/27/2013 08:00 PM, Ranjan Maitra wrote:
On Mon, 28 Jan 2013 10:55:24 +1100 Philip Rhoades phil@pricom.com.au wrote:
People,
Date: Sun, 27 Jan 2013 15:18:40 -0500 From: "Eddie G. O'Connor Jr." eoconnor25@gmail.com To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: humble suggestion to Fedora developers Message-ID: 51058BA0.8020509@GMail.com Content-Type: text/plain; charset=UTF-8; format=flowed
On 01/23/2013 02:59 PM, James Freer wrote:
On Wed, Jan 23, 2013 at 7:34 PM, Joe Zeff joe@zeff.us wrote:
On 01/23/2013 06:53 AM, Reindl Harald wrote:
because first new anaconda was approved and integration all over the distribution started and after that damage was done people realized "hm new anaconda is not ready"
So what you're saying is, it was approved before it was ready. Judging from what else you wrote, the devs didn't realize it when they approved it. This suggests to me that approval came too early in the process, before proper testing was done and that important parts of the program hadn't been completed. If so, is there anything that can be done to prevent this from happening yet again?
I have the greatest respect for the developer's that put in considerable effort for each release. The problem with 6 month release cycle is too little time. I've used linux now for almost 6 years with Ubuntu and Fedora. Some distros use a two year release which is too long. One or two use an annual release which i think is about right... development and testing can fully take place. Why not consider an annual release which would give appropriate time for all to take place?
james
I would have to agree with you James, it might not be a bad idea for them to stretch their release time out a bit? I would have positives from all sides. First,....the developers would be able to REALLY put their apps and what-not through a GRUELING testing session, this way...when they say it works.....IT WORKS! Second,.....the public wouldn't find themselves scurrying to acquire the latest version, and slamming it onto their machines without knowing that things won't crash & burn un-necessarily......also it would give the public time to "adapt" and become comfortable with the latest release, instead of going into shock at the arrival of a new desktop environment...or new feature-sets that were not there before. I guess it's just a matter of someone (or a LOT of someone's) voicing their opinion loud enough to be heard by the higher-ups? I don't know that they would actually change things around like that....(it would be NICE!) but eventually they might get restless enough to completely flip thing around and have longer time frames between releases.
Maybe we should try out, say, a nine month cycle and if it doesn't suit
- go back to six months? I am conscious though of the human tendency to
put off things when there is more time to get them done . .
But the rush to release will still be there, whether it is a 6- or 9- or 12-month cycle? At the point of release, inadequately-tested new features may still be a problem, no?
I think a more reliable approach is to have a rolling release model, with periodic snapshot RPMs in a cycle? The periodic snapshots could be benchmark-based, so no specific time schedule, rather than calendar-based?
Ranjan
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
Now THIS sounds feasible, and it would make for a smoother transition from one release to the next! I wonder whom I would have to speak to.....to see if this could be done? Or is it a group thing?.....would I direct something like this towards the kernel maintainers?....the admins?.....who would get "the call"?...
EGO II
Allegedly, on or about 27 January 2013, Ranjan Maitra sent:
But the rush to release will still be there, whether it is a 6- or 9- or 12-month cycle? At the point of release, inadequately-tested new features may still be a problem, no?
I think a more reliable approach is to have a rolling release model, with periodic snapshot RPMs in a cycle? The periodic snapshots could be benchmark-based, so no specific time schedule, rather than calendar-based?
I tend to agree.
You could, very easily, be testing a distro in preparation for its general release, with all looking well. But it only takes an updated package, or two, to stuff things up. It might pass the testing, at the time, but last minute packages wouldn't have had the amount of testing, under more varied circumstances, than packages that have been their for longer.
It's not such a huge problem when its something like Firefox, which can be replaced by an post-install update. But when something that's required to do the installation is screwed up, that is a big problem.
Likewise, things that are core to the distro become a big problem, if the plan is not to replace them during that release.
On Mon, Jan 28, 2013 at 10:55:24 +1100, Philip Rhoades phil@pricom.com.au wrote:
Maybe we should try out, say, a nine month cycle and if it doesn't suit - go back to six months? I am conscious though of the human tendency to put off things when there is more time to get them done .
This was done once (intentionally) and it didn't really seem to help much. Most changes can be done smoothly with 6 month releases. We need get better at handling the big changes that take longer. There are a lot of those and there isn't any particular time that would be long enough in all cases. So I'd rather have us figure out efficient ways to do these kind of projects.
On Sun, Jan 27, 2013 at 20:04:30 -0500, "Eddie G. O'Connor Jr." eoconnor25@gmail.com wrote:
Now THIS sounds feasible, and it would make for a smoother transition from one release to the next! I wonder whom I would have to speak to.....to see if this could be done? Or is it a group thing?.....would I direct something like this towards the kernel maintainers?....the admins?.....who would get "the call"?...
Rolling releases work OK until you need to make a big change and then they aren't so good. There are people looking to make rawhide more usable and if you want a rolling release that's it. (Rawhide is usable most of the time, but occasionally something will break at an inconvenient time. Kevin Fenzi is collecting some ideas for how to isolate some people from that brokeness, so that it is mor usable for normal people.)
On 27 Jan 2013, at 23:55, Philip Rhoades phil@pricom.com.au wrote:
People,
Date: Sun, 27 Jan 2013 15:18:40 -0500 From: "Eddie G. O'Connor Jr." eoconnor25@gmail.com To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: humble suggestion to Fedora developers Message-ID: 51058BA0.8020509@GMail.com Content-Type: text/plain; charset=UTF-8; format=flowed On 01/23/2013 02:59 PM, James Freer wrote:
On Wed, Jan 23, 2013 at 7:34 PM, Joe Zeff joe@zeff.us wrote:
On 01/23/2013 06:53 AM, Reindl Harald wrote:
because first new anaconda was approved and integration all over the distribution started and after that damage was done people realized "hm new anaconda is not ready"
So what you're saying is, it was approved before it was ready. Judging from what else you wrote, the devs didn't realize it when they approved it. This suggests to me that approval came too early in the process, before proper testing was done and that important parts of the program hadn't been completed. If so, is there anything that can be done to prevent this from happening yet again?
I have the greatest respect for the developer's that put in considerable effort for each release. The problem with 6 month release cycle is too little time. I've used linux now for almost 6 years with Ubuntu and Fedora. Some distros use a two year release which is too long. One or two use an annual release which i think is about right... development and testing can fully take place. Why not consider an annual release which would give appropriate time for all to take place? james
I would have to agree with you James, it might not be a bad idea for them to stretch their release time out a bit? I would have positives from all sides. First,....the developers would be able to REALLY put their apps and what-not through a GRUELING testing session, this way...when they say it works.....IT WORKS! Second,.....the public wouldn't find themselves scurrying to acquire the latest version, and slamming it onto their machines without knowing that things won't crash & burn un-necessarily......also it would give the public time to "adapt" and become comfortable with the latest release, instead of going into shock at the arrival of a new desktop environment...or new feature-sets that were not there before. I guess it's just a matter of someone (or a LOT of someone's) voicing their opinion loud enough to be heard by the higher-ups? I don't know that they would actually change things around like that....(it would be NICE!) but eventually they might get restless enough to completely flip thing around and have longer time frames between releases.
Maybe we should try out, say, a nine month cycle and if it doesn't suit - go back to six months? I am conscious though of the human tendency to put off things when there is more time to get them done . .
Regards,
Phil.
I think if nine months was tried then the interim period should be renamed a gestation.
I'd also like to add to the pile of anecdotal evidence that my systems been stable since upgrading to F18. There were some hiccups with evolution but that was more to do with my self-signed server certs than anything.
On 01/27/2013 10:42 PM, Tim wrote:
Allegedly, on or about 27 January 2013, Ranjan Maitra sent:
But the rush to release will still be there, whether it is a 6- or 9- or 12-month cycle? At the point of release, inadequately-tested new features may still be a problem, no?
I think a more reliable approach is to have a rolling release model, with periodic snapshot RPMs in a cycle? The periodic snapshots could be benchmark-based, so no specific time schedule, rather than calendar-based?
I tend to agree.
You could, very easily, be testing a distro in preparation for its general release, with all looking well. But it only takes an updated package, or two, to stuff things up. It might pass the testing, at the time, but last minute packages wouldn't have had the amount of testing, under more varied circumstances, than packages that have been their for longer.
It's not such a huge problem when its something like Firefox, which can be replaced by an post-install update. But when something that's required to do the installation is screwed up, that is a big problem.
Likewise, things that are core to the distro become a big problem, if the plan is not to replace them during that release.
Well what are the odds that ANY of these suggestions will actually be considered and / or acted upon?...And I only ask out of curiosity...
EGO II
-
Bruno Wolff III -
EGO-II.1 -
Junk -
Philip Rhoades -
Ranjan Maitra -
Tim