fedora 11 worst then ever release

David Cantrell dcantrell at redhat.com
Mon Jul 27 19:41:23 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 27 Jul 2009, Ralf Corsepius wrote:

> On 07/27/2009 11:26 AM, David Cantrell wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> On Mon, 27 Jul 2009, Ralf Corsepius wrote:
>> 
>>> On 07/27/2009 07:33 AM, David Cantrell wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> 
>>>> On Sun, 26 Jul 2009, Björn Persson wrote:
>>>> 
>>>>> Ralf Corsepius wrote:
>>>>>> On 07/26/2009 02:37 PM, Seth Vidal wrote:
>>>>>>> On Sat, 25 Jul 2009, Alan Cox wrote:
>>>>>>>> "all of my system has a wrong openssl version"
>>>>>>>> 
>>>>>>>> all these symptoms sound like your upgrade went horribly wrong. I've
>>>>>>>> seen preupgrade mash up a box by half upgrading like that. It's the
>>>>>>>> main
>>>>>>>> reason
>>>>>>>> I don't think preupgrade is actually safe to use yet.
>>>>>>> 
>>>>>>> Preupgrade's process is to depsolve - using the same method anaconda
>>>>>>> does, download the pkgs it solves out. Put them in a cachedir.
>>>>>>> Download
>>>>>>> a kernel and an initrd, Setup a ks.cfg. then reboot the machine and
>>>>>>> allow anaconda to do the install.
>>>>>>> 
>>>>>>> Specific issues we've had with preupgrade are related to not being
>>>>>>> able
>>>>>>> to find a mirror and/or not being able to get pkgs.
>>>>>> 
>>>>>> Mine were
>>>>>> * preupgrade running out of diskspace on / when trying to fill
>>>>>> /var/cache/yum (my "/"'s tend to be minimized/small)
>>>>> 
>>>>> You're not blaming Preupgrade for the partition being too small, are
>>>>> you? If
>>>>> you want a small root partition you should put /var/cache/yum on
>>>>> another
>>>>> partition.
>>>>> 
>>>>> Do you mean Preupgrade didn't handle the lack of disk space well?
>>>>> 
>>>>>> * anaconda failing during reboots due not being able to process fstab
>>>>>> correctly (FC11's anaconda misparses fstab and is unable able to
>>>>>> process
>>>>>> bind-mounts nor nfs-mounts).
>>>> 
>>>> Bind mounts are fixed, as far as I know:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=496406
>>>> 
>>>> For NFS mounts, I believe it's fixed in commit
>>>> 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That
>>>> should
>>>> carry over NFS mounts listed in /etc/fstab if you are doing an upgrade.
>>> Well, to my knowledge these are "FIXED RAWHIDE", only.
>>> 
>> 
>> That's true. anaconda is unique in that the only way a new one can be
>> released to fix installation issues for users is to generate new media.
> Exactly => this bug is _not fixed_.
>
>
>> We continue to fix problems reported against Fedora 11's anaconda in
>> rawhide,
>> but for users needing the fix in the latest stable release, consider Fedora
>> Unity. Fedora Unity generates new spins of the latest stable release
>> including backports of anaconda fixes:
>> 
>> http://www.fedoraunity.org/
> With all due respect to fedoraunity and you. To me it is a serious Fedora 
> management and rel-eng mistake causing major harm to fedora's and RH's 
> reputation to not provide updated media, thus to expose users to known bugs.
>
> Openly said, I think this management mistake is one of the culprits for the 
> poor shape of Fedora.
>
> Another one is not having banned "FIXED RAWHIDE/UPSTREAM".

The problem here is when do you stop generating new media to fix bugs in
F-11's installer and start working on F-12?  Never?  A week after F-11 GA?
What determines if an installer bug gets a fix in F-11 vs. not?

It's a gigantic waste of time for the installer team to release updates to
F-11's installer.  We can address those bugs in rawhide and have them fixed in
the next stable release.  Generating new media for an existing release is not
a great solution.  The mirrors are already synced up with the GA release.

Here's what we do and I think it works best for now given the incredibly short
(and damn near impossible to work with) planning and development windows for
Fedora releases:

1) Major installation problems are documented on the Common Bugs wiki page for
the Fedora release in question.  Either a workaround or updates.img file is
provided to fix the issue.

2) New bugs come in and we address them in rawhide.  Where we run in to issues
here is asking people to test the next build of rawhide.  Not everyone wants
to do that (or can, has time, etc).  But spending our time producing new media
and/or updates.img files for F-11 takes away from our time to work on F-12.
This is where I think Fedora Unity can bridge the gap.  They can pick up fixes
for F-11 installation problems and roll new media for users.  That provides a
non-rawhide solution for the reporter, lets the bug at least get some testing,
and frees us [installer team] from having to produce media or updates.img
files for F-11.

A larger problem we have is that we don't get the wide testing on the Alpha,
Beta, or Release Candidate releases of the upcoming Fedora release.  The same
group of people generally test things out and the QA team performs their
tests, but we never get the same testing exposure that a GA release does.
Most users are sitting around waiting for the GA release and when they find a
bug, it's too late for us to do anything about it in that release.

Maybe if we lengthened the development cycle for a Fedora release and renamed
Alpha, Beta, and RC to .0, .1, and .2, users would think differently of each
release.

- -- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpuAuQACgkQ5hsjjIy1Vkn5KACaAnsQG9dR1+JMIwyLXLKpR9Cs
HQcAn08eYetKLYGPgXIH5hk30DlEqrcD
=AVY1
-----END PGP SIGNATURE-----


More information about the fedora-devel-list mailing list