the danger of becoming a cargo cult

Thorsten Leemhuis fedora at leemhuis.info
Thu Mar 1 06:09:13 UTC 2007


On 28.02.2007 18:07, Christopher Blizzard wrote:
> On Tue, 2007-02-27 at 07:30 +0100, Thorsten Leemhuis wrote:
>> Agreed -- but nevertheless *I* still have the impression that Red Hat 
>> and Fedora developers work to much with upstream on improving the Linux 
>> software stack (which is a good thing in general, but: ) and don't care 
>> enough about our distribution specific stuff.
>> Ubuntu is much more active in that area and thus has some interesting 
>> stuff that we are already still working on (codec buddy) or have on our 
>> Roadmap (say: new initsystem). That makes them much more attractive 
>> these days afaics, as they also get the improvements Red Hat has worked 
>> out automatically, too (often before we ship them).
>> To say it in another way: In the past it was Red Hat Linux that lead the 
>> way (upstream and in the distribution) and others had to catch up under 
>> the risk to run into a "Cargo Cult". These days it seems to be Ubuntu.
> I've had this conversation with Jonathan in the past, who has
> articulated better than most.  He feels that working upstream instead of
> Fedora gives him the most leverage and can drive the direction of the
> desktop.  And he's right, we've been hugely successful at building
> healthy upstream projects that make our jobs much easier here in Fedora.

I agree with this fully. But we have a lot of stuff that is special to 
Fedora (say anaconda, pup, pirut, initscripts) -- that afaics an area 
where we need more improvements. When it comes to those improvements 
it's often Jeremy that does them or at leasts coordinates them.

He does it great, but we afaics could need two or three Jeremy's for all 
the stuff that is lingering around undone for a long time. Just some 
days ago there was this commit in the wiki:

http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems?action=diff&rev2=6&rev1=5
Commit text: "I'm doing this? At this point, not likely to happen for F7 
unless someone wants to start contributing patches"

Installing packages with yum/pirut from CD/DVD is another example that a 
lot of people asked for a long time already, but Jeremy didn't find time 
for it.

> The downside to that is that Fedora's users are the _last_ to benefit
> from the work that Red Hat has funded.

I would not say the "last", but yes, often it are others that get them 
earlier. Especially those in Gnome, as other Distros have a time based 
release schedule that is close to the one from Gnome.

> It's one of the reasons why a healthy and open Fedora is so important to
> me personally.

+1

>  In a system in which package ownership and maintenance
> can be done by both people inside of Red Hat and outside, we get the
> best of both worlds.   Strong upstream work by full-time developers and
> an excited and engaged user/developer base that feels ownership and can
> do the early and final integration that Red Hat has failed to do because
> they are too busy fixing upstream issues.

Maybe -- but some tasks are quite big, and then often a helping and 
guiding hand from someone that is paid for his work and has ~30 minutes 
for it each day for it makes the difference.

> This is also connected to why I feel why it's so important that we
> figure out a better way to handle source, patches and packaging - maybe
> including source-as-SCM.  Early development and testing mediates some of
> the the Fedora-has-best-practices-but-still-ends-up-last problem.
> (Loved by upstream projects and developers, used by few.)

Agreed. But as I said: the focus for my "rant" that you replied to was 
more on the Fedora-specific stuff (say for example the Encrypted 
Filesystems, where the underlying technology IMHO should be worked on 
upstream, but we need to use it) where we need more improvements to make 
Fedora more interesting.

Take the LiveCD as a example: It took much to long time to get where we 
are now -- we could have been there where we are now two or three years ago.

CU
thl




More information about the advisory-board mailing list