[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: My roadmap for a better Fedora

On Wed, 2008-11-19 at 12:38 -0600, Callum Lerwick wrote:
> So, many pieces of this have been blabbed about by me and others
> recently and in the past, but I think a lot of people aren't seeing the
> big picture. I think it's time I fit it all together.
> Problem: Fedora is buggy, and updates are rife with regressions.
> Solution: We need more and wider testing.
> Problem: We need more and wider testing. Why don't we get more testing?
> Thw reason *I* don't go out of my way to test updates, is if there's a
> regression, it's such a pain in the ass to get the system back to a
> known good state and keep it that way, and report a bug. If it's a pain
> in the ass for me, it's impossible for Aunt Tillie.
> Solution:
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks. It should automatically include
> all the information needed for the bug report, the distro version,
> package version, arch, and things such as how the Xorg team demands your
> xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> traces system wide and enter them in a database, which bugzilla can
> reference and from which bugzilla bugs can be derived. A system wide
> kerneloops. (I know this has been talked about, what's the status?)
> 2) Make it simple to roll back to a known good state. We need a "system
> restore". I know what you're thinking, but our vastly superior,
> centralized, system-wide package management (and lack of a whole
> seperate "system registry" namespace) allows us to make this actually
> work. We need per-package rollback. Period.
> 3) Make it so yum will refuse to upgrade the package rolled back in step
> 2 until the bug reported in step 1 is fixed.
> 4) For when things go really wrong, we need a rescue image in /boot. All
> the above functionality must be available inside the rescue environment.
> 5) So how do bugs get fixed? Make it easy to cherry pick updates from
> updates-testing or even direct from bodhi. How useful is it to blindly
> follow every update in updates testing? For most users, it's useless.
> Such adventurous people should probably just run rawhide... What we
> really need is to make it easy to pick a specific release of an update
> to try, such as if a user is directed to in a bug report. A user should
> just be able to click on a link given in the bug report and have the
> update installed. Available updates and the reasons for them needs to be
> more discoverable. Don't forget step #2.
> See how these things build upon and support each other?
> Notice here I'm talking purely about user interface, about the end user
> experience. The technical infrastructure follows from this, and I'll
> save that discussion for another message. Infrastructure supports
> functionality, not the other way around. I don't want to hear any "Oh
> but we can't do this because blah blah technical objection blah makes
> this hard". I hereby dub this the "Hard problem fallacy". Engineers
> solve hard problems, that's what we do. I want to hear "To do this we
> need to do x y z". The only objections I will accept are of the form
> "You are an idiot and your ideas are stupid. We're not doing this."
> I should probably put this on the Wiki so it doesn't get lost...


Doug Ledford <dledford redhat com>
              GPG KeyID: CFBFF194

Infiniband specific RPMs available at

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]