Rahul Sundaram <sundaram@xxxxxxxxxxxxxxxxx>: > We only have your analysis of the problem. Not a description of the > actual problem. That would be more helpful. Perhaps a bug report. You have half of it. rpm should be statically linked to avoid this sort of cul-de-sac. It's not like multople instances of it running are going to be a frequent occurrence. I can tell you the library in question was libcom_err, and I think I deleted it when removing e2fsprogs-libs to get around a file conflict. But with rpm not working I couldn't reinstall the library. Boot failed, ssh/sshd failed -- I had to kluge with netcat and tar just to back up my files. It was horrible. Alas, I no longer have the logs, as I lost them during installation. I don't recall what the file was, but the conflict was completely avoidable and would never have occurred if the repo and RPMs had been in a sane state. > >* Chronic governance problems. > > More details required. I have a special interest in this. I was thinking of the the endless internal wrangling over what to do about the core/extras split, and the years the project has spent failing to engage with third-party developers and repo maintainers. That IRC-session parody of Fedora politics somebody wrote back around 2002 remains as painfully on-point today as it was then. The Fedora project has never resolved the tension between Red Hat's business need for it to be an adjunct of RHEL development and its core group's stated aim to be community-facing. The result is a sociology that has increasingly combined the least useful features of a corporate project with the least useful snakepit-like features of 'community' politics -- as perfectly illustrated by the list response to my goodbye note. > >* A murky, poorly-documented, over-complex submission process. > > Last time you claimed this, I requested you to point out specific issues > which you agreed to. That was never delivered. Your actual submission > was struck after the reviewer pointed out some things to fix I was doing what I told Jesse Keating I'd do -- using that submission as a probe of the process, and planning to write up a narrative of the difficulties and some recommendations once it was done. (I'll note that I thought the reviewer did a good job of critique, so the early indications were somewhat positive.) The things I could address in that particular submission were trivial and are fixed, as I noted in a comment attached to the bug. I was waiting on resubmitting until Mike Smith shipped a new stylesheet RPM, as that was critical to fixing the man-page glitches. Now it's no longer my problem. > >* Allowing RPM development to drift and stagnate -- then adding > > another layer of complexity, bugs, and wretched performance with yum. > > RPM indeed drifted but I dont think it actually stagnated. Anyway > http://rpm.org for more details. RPM doesnt do automatic dependency > resolving. Yum does. I did read somewhere your claim that introducing > yum was a big change that put Fedora in a position of advantage or some > such thing. Yes, I thought so at the time. But yum failed to live up to what I thought was considerable early promise. It remained painfully slow and buggy. Improvements in dependency resolution that seemed conceptually obvious to me were never made. The most obvious of these would have been a clique analysis of mass updates to fail the smallest possible subset hanging on a missing dependency, rather than failing the entire update. I used to be a mathematician, I have the graph-theory chops to do something about this, and I tried to contribute some refactoring patches that would have led in this direction. They were rejected, and I had other things to do. > >* Effectively abandoning the struggle for desktop market share. > > Unless this is just about proprietary codecs, Red Hat continues to do a > lot of work on the desktop To no visible result. You had the developers, the first-mover advantage, and the corporate backing; you lacked the vision and the will to follow through. Ubuntu shows what could have been done -- but if you guys had executed correctly, Ubuntu's market- and mindshare would be at best statistical noise (if it existed at all). > >* Failure to address the problem of proprietary multimedia formats with > > any attitude other than blank denial. > > We spend a lot of time even recently on FUDCon Boston 2007 discussing > this. See http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy Again, to no visible result. And with zealots screaming their heads off against it whenever the topic came up on fedora-devel. I wound up expecting that any Fedora 'solution' would be half-hearted and ineffective and involve far too much sneering at users' actual needs and too little effort spent on actually meeting them. The wiki page does nothing to disabuse me of this expectation by using terms like "brainwashing". The contempt for mere users this exhibits is very revealing, and is a significant part of the reason I've decamped. Meanwhile, Ubuntu and Linspire are actually addressing the problem at its root. They might get it solved in time to meet the 64-bit deadline Rob Landley and I have seen coming, but Fedora clearly will not. So much for Fedora. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
