I'm adding the fedora-devel-list as I think this should be discussed there.
Andre Costa escribió:
Hi folks,
bug #372011 [https://bugzilla.redhat.com/show_bug.cgi?id=372011] is hosting a heated debate about anaconda & F8, how this dreadful bug has been hurting F8 reputation and so on (I'm one of the poor souls that have been affected by it -- and have been saved by patched .img provided by Jeremy Katz [http://katzj.fedorapeople.org/updates-f8-yumloop.img]).
It has hurted very much I must say.
One thing that's clear is that anaconda QA missed some key spots, and also that we (users) didn't help much on the process, allowing the bugs to remain hidden until the version was officially released, which led to a lot of stress among users and developers.
The problem is that most users don't have time and resources to test twice a year a new release. 6 months for development+beta testing+RC testing is just too little. IMHO.
Also, what kind of QA does Fedora have today? I'm not throwing mud at anyone, it's just that I don't have the slightest idea! (As Lucy used to say in the Peanuts Gang). There should be a list of things that have to be tested, and for each one of them, testers should report on the output of the test. Some items are more critical then others, and so should have more test reports.
Just some ideas that just cracked out of my head. :-D
I would really like to participate more during the beta stage of new Fedora versions. However, as I stated on Comment #97 [https://bugzilla.redhat.com/show_bug.cgi?id=372011#c97] I can't really install beta versions on my system at home, I use it daily, including for work.
This is exactly what I stated before: you don't have the resources.
But, AFAICS the other aspects of the installation process are pretty much stable and independent from the current installation (language selection, keyboard selection etc.), and the critical step for an upgrade is dependency solving / package selection.
So, what if the developers provided early access to this particular part of anaconda only? I mean, in read-only mode, it would just gather information about the packages currently installed and confirm if it would be able to handle an upgrade on a "real" installation scenario? It could for instance stop right after depsolve and show some statistics.
Well, nobody could ensure that the beta anaconda will not bite your disk. It is pre-beta.
Believe me, if I was sure that I could test anaconda in read-only mode I would gladly do it, at any step before the official release. Chances are that test coverage would improve considerably, and no installation would be touched during this process.
Does this make any sense to anyone? Would this help? Is it already possible somehow?
What I do see as something Fedora Project should do is whats commented in comment #104 [https://bugzilla.redhat.com/show_bug.cgi?id=372011#c104] about information on the web page of how to collaborate with the project.
What would be a hugh plus for the project.
Martin Marques wrote:
One thing that's clear is that anaconda QA missed some key spots, and also that we (users) didn't help much on the process, allowing the bugs to remain hidden until the version was officially released, which led to a lot of stress among users and developers.
The problem is that most users don't have time and resources to test twice a year a new release. 6 months for development+beta testing+RC testing is just too little.
It seems that someone in a marketing department assumed that people will be frightened by 6 month cycle and will *buy* more stable distribution kit (RHEL) instead. The people were actually frightened. What they are using now? Yep, CentOS and friends. Free of charge. And free of necessity to test new release *at all* </sarcasm>
Fortunately, recently the policy was changed -- now EOL for a N release is 1 month after (N+2) time. Thus you can test a new release just 1 time per year.
Just my 2 cent.
Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy
Dmitry Butskoy wrote:
Martin Marques wrote:
One thing that's clear is that anaconda QA missed some key spots, and also that we (users) didn't help much on the process, allowing the bugs to remain hidden until the version was officially released, which led to a lot of stress among users and developers.
The problem is that most users don't have time and resources to test twice a year a new release. 6 months for development+beta testing+RC testing is just too little.
It seems that someone in a marketing department assumed that people will be frightened by 6 month cycle and will *buy* more stable distribution kit (RHEL) instead.
Nope. Red Hat Linux itself followed a similar release schedule so this has nothing to do with Fedora/RHEL splut. Besides you can't explain various other distribution that have a 6 month release cycle this way. Answer lies in rest of the upstream software including GNOME which follow this release schedule and user demands for those software which are usually too intrusive to include as updates in a general release.
Rahul
Rahul Sundaram wrote:
Dmitry Butskoy wrote:
Martin Marques wrote:
One thing that's clear is that anaconda QA missed some key spots, and also that we (users) didn't help much on the process, allowing the bugs to remain hidden until the version was officially released, which led to a lot of stress among users and developers.
The problem is that most users don't have time and resources to test twice a year a new release. 6 months for development+beta testing+RC testing is just too little.
It seems that someone in a marketing department assumed that people will be frightened by 6 month cycle and will *buy* more stable distribution kit (RHEL) instead.
Nope. Red Hat Linux itself followed a similar release schedule so this has nothing to do with Fedora/RHEL splut.
Not exactly. Old releases of Red Hat Linux was supported much more time rather than Fedora now.
Besides you can't explain various other distribution that have a 6 month release cycle this way.
Yep, I can't :)
Answer lies in rest of the upstream software including GNOME which follow this release schedule
BTW, what else significant besides GNOME?
and user demands for those software which are usually too intrusive to include as updates in a general release.
But it seems intrusive anyway, because the user is compelled to switch to the new release fast enough...
Dmitry
Dmitry Butskoy wrote:
Not exactly. Old releases of Red Hat Linux was supported much more time rather than Fedora now.
Release cycle is different from updates cycle and IIRC the last couple of releases of Red Hat Linux wasn't supported much longer. Anyway the point is that ~ 6 month release cycle was adopted from Red Hat Linux.
Answer lies in rest of the upstream software including GNOME which follow this release schedule
BTW, what else significant besides GNOME?
Time based releases? Openoffice.org, Xorg, Linux kernel ...
But it seems intrusive anyway, because the user is compelled to switch to the new release fast enough...
You know it is going to a major decision compared to updates for a existing release. That visibility is important I think. There are other distributions that have been following a rolling release model. Source based: Gentoo.. Otherwise: Arch and a few others.
Rahul
On Mon, 26 Nov 2007 20:00:21 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
Dmitry Butskoy wrote:
Not exactly. Old releases of Red Hat Linux was supported much more time rather than Fedora now.
Release cycle is different from updates cycle and IIRC the last couple of releases of Red Hat Linux wasn't supported much longer. Anyway the point is that ~ 6 month release cycle was adopted from Red Hat Linux.
Answer lies in rest of the upstream software including GNOME which follow this release schedule
BTW, what else significant besides GNOME?
Time based releases? Openoffice.org, Xorg, Linux kernel ...
The kernel doesn't exactly have a time based release. It's fairly predictable as to when the next one will happen, but it doesn't follow an explicit timeline.
josh
Josh Boyer escribió:
The kernel doesn't exactly have a time based release. It's fairly predictable as to when the next one will happen, but it doesn't follow an explicit timeline.
Also, Fedora includes different kernel version is the same release, so releases of Fedora are not because of kernel releases.
On Mon, Nov 26, 2007 at 13:00:31 -0300, Martin Marques martin@marquesminen.com.ar wrote:
Josh Boyer escribió:
The kernel doesn't exactly have a time based release. It's fairly predictable as to when the next one will happen, but it doesn't follow an explicit timeline.
Also, Fedora includes different kernel version is the same release, so releases of Fedora are not because of kernel releases.
That isn't exactly true. For example the libata change was held off until a new release of Fedora.
On Mon, 26 Nov 2007 17:42:30 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
Answer lies in rest of the upstream software including GNOME which follow this release schedule
From what I've been told, GNOME got into the habbit of a 6 month cycle because they wanted to be included in the next Red Hat Linux release, which had a 6 month cycle....
Jesse Keating wrote:
On Mon, 26 Nov 2007 17:42:30 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
Answer lies in rest of the upstream software including GNOME which follow this release schedule
From what I've been told, GNOME got into the habbit of a 6 month cycle because they wanted to be included in the next Red Hat Linux release, which had a 6 month cycle....
Kind of. Havoc mentioned what happened at
http://osdir.com/ml/redhat.fedora.advisory-board/2006-12/msg00093.html
Rahul
Jesse Keating escribió:
On Mon, 26 Nov 2007 17:42:30 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
Answer lies in rest of the upstream software including GNOME which follow this release schedule
From what I've been told, GNOME got into the habbit of a 6 month cycle because they wanted to be included in the next Red Hat Linux release, which had a 6 month cycle....
Hey, which one is the egg? ;-)
Dmitry Butskoy wrote:
Martin Marques wrote:
One thing that's clear is that anaconda QA missed some key spots, and also that we (users) didn't help much on the process, allowing the bugs to remain hidden until the version was officially released, which led to a lot of stress among users and developers.
The problem is that most users don't have time and resources to test twice a year a new release. 6 months for development+beta testing+RC testing is just too little.
It seems that someone in a marketing department assumed that people will be frightened by 6 month cycle and will *buy* more stable distribution kit (RHEL) instead.
Red Hat Linux itself followed a similar release schedule so this has nothing to do with Fedora/RHEL split. Besides you can't explain various other distribution that have a 6 month release cycle this way. Answer lies in rest of the upstream software including GNOME which follow this release schedule and user demands for those software which are usually too intrusive to include as updates in a general release.
Rahul