mether's Fedora Blog

Random thoughts, usually on Fedora

On what our values are

LWN has a article (http://lwn.net/Articles/195824/) on what it describes as a house keeping exercise and probably can be described as such considering that we are at present merely going through a licensing audit to comply with existing packaging guidelines but as someone who has been initiating this process (credit to Tom Callaway for doing all of the actual hard work) it goes much more beyond that.

As Michael Tiemann pointed out in FAB (https://www.redhat.com/archives/fedora-advisory-board/2006-April/msg00170.html) and as Max Spevack highlighted (http://interviews.slashdot.org/article.pl?sid=06/08/17/177220) distributions like Ubuntu do include non-free software (Binary only Nvidia drivers) in their releases and in their infrastructure (launchpad,malone,rosetta..) and Fedora should be meeting its objectives (http://fedoraproject.org/wiki/Objectives) and do so in the best way possible and provide unique values at that.

Luis Villa has spawned a series of blogs starting off of the recent much publicised Xorg update breakage (http://osnews.com/comment.php?news_id=15587) in Ubuntu http://tieguy.org/blog/2006/08/22/still-learning-what-long-term-support-means/) that ended up being a very interesting discussion (http://tieguy.org/blog/2006/08/23/notes-about-distros-qa-etc/) touching various aspects of how you focus on QA (http://tieguy.org/blog/2006/08/24/more-on-qa-ubuntu-trust-etc/).

He points out that

* Fedora is now support upgrades between distributions – I believe he is talking about live upgrades using yum rather than using the Anaconda installer (which has always been supported). I havent heard of anything public posturing on this but as I pointed in my overview of Fedora Core 5 in http://www.redhat.com/magazine/018apr06/features/fc5_overview/, the use of yum within Anaconda as a dependency resolving mechanism means that we could cut down the differences between upgrades using yum and ones using Anaconda. The recent Fedora Core switchover to brew ( part of which is a mock based buildsystem similar to the one in Fedora Extras would also help in upgrades by ensuring (and even mandating) that we can do a better job in packaging by making the dependencies much more explicit which is a process being tracked at http://fedoraproject.org/wiki/QA/FixBuildRequires. If we are running into issues with live upgrades that are usually caused by dependency issues we need to fix anyway. So lets see how this goes.

* Fedora has a rapidly growing software repository – These two factors (along with others like getting our basic packagement tools in order with yum, pirut, pup and puplet) would provide good competition to the Debian crowd.

* Fedora shouldnt in general provide major updates in between distributions such as Xorg 7.1 – This is a position I am very much supportive of now and argued in http://fedoraproject.org/wiki/UpdatesPolicy. I suspect I might lose on this one though and I hope that we can do a better job on this.

* Fedora should focus on QA efforts – Agreed again. Everyone keep a eye on the roadmap of Fedora automated testing framework at http://fedoraproject.org/wiki/QA/Beaker. Will Woods is our man on this. If we get this thing effort right, we would have made a major leap ahead as the first community distribution to provide transparent and open automated testing on a daily basis.

Written by mether

August 26, 2006 at 2:56 am

Posted in Uncategorized

One Response

Subscribe to comments with RSS.

  1. You should really make the text be the link. No one wants to read URLs. Compare:

    “in my overview of Fedora Core 5 in http://www.redhat.com/magazine/018apr06/features/fc5_overview/

    “in my overview of Fedora Core 5

    ajaxxx

    August 26, 2006 at 12:45 pm


Comments are closed.

%d bloggers like this: