[MythDora] MythDora Update Idea

[Chris]

Axel Thimm wrote:
> On Thu, Jul 03, 2008 at 09:05:07PM -0400, gchris wrote:
>> I recently had occasion to build a new Fedora 8 system and noted that 
>> the huge pile of Fedora updates (324) cured many of the non-MythDora 
>> bugs found in the MD5 beta test, and which still trip up an occasional 
>> new MythDora user.
>>
>> I completely agree with Dennis' practice of discouraging users from 
>> randomly applying updates to his distro and the shear volume of Fedora 
>> updates shows the wisdom of that approach.  Nonetheless, there are known 
>> bugs that have Fedora fixes and there is an eager posse of beta-testers 
>> just waiting to sink their teeth into the next release.
>>
>> My thought was that it might be worthwhile to identify a top 5 or top 10 
>> list of non-MythDora bugs and encourage beta testers to watch for and 
>> test Fedora updates related to those bugs.  When a particular bug is 
>> verified fixed without negative effects by two or more beta testers, 
>> that fix gets designated as a MythDora Approved fix and the first or 
>> first and second reporters get credited on the MythDora website for 
>> finding that solution.  Tracking of the attempts and successes or 
>> failures might be handled by Jarod's bug tracking facility.
>>
>> The goal would be to promote manageable, disciplined improvements of 
>> each MythDora release from womb to tomb without the potential 
>> destabilization of wholesale upgrades.
>>
>> Thoughts? Concerns? Opinions?
>> Chris
> 
> I think everybody will have a different top 5 of bugs he'd like to see
> fixed. I'd recommend either
> 
> a) a (bi)-monthly reissue of a minor mythdora release carrying the
>    accumulated updates, or
> b) rebasing mythdora to RHEL5/6 (actually then CentOS5/6), which have
>    far less updates to worry about (and the updates are much more safe
>    to apply)
> 
> The problem with a) ist that one would need to do at least some basic
> QA on each minor release. The problem with b) is that the tools used
> for Fedora may not work with RHEL, but I think Jarod and Jeremy were
> looking into pungi on RHEL5, so maybe this is now feasible.

Dennis is the decider.
a) Besides requiring a lot of testing to maintain QA, also requires a 
lot of extra iso downloading and CD burning and doesn't target specific 
user complaints.  It's a shotgun approach to solving problems where a 
rifle is the weapon of choice.  A specific example:  Fedora 8 hangs when 
shutting down from a KDE desktop.  That problem is real and repeatable 
and is fixed in one of the 320+ Fedora updates.  Tell me which one and 
I'll fix it, but don't expect me to keep downloading and burning CDs in 
hopes that one of them might fix it.
b) Is a wonderful solution, or would be if those old kernels were smart 
enough to load the correct drivers and firmware in the correct order for 
my tuners and capture cards.  The Fedora kernels do that for me.  I 
might be able to splice a Fedora kernel into CentOS5/6 but if I did 
that, how much of that legendary stability would be lost in the process?
And how many custom RPMs would I need to glue the old and new together?
Chris