On Fri, 5 Nov 2004, Michael Schwendt wrote: > On Fri, 5 Nov 2004 16:05:00 +0100 (CET), Dag Wieers wrote: > > > > > http://www.fedora.us/wiki/RepositoryMixingProblems > > > > > > That page also explains why fedora.us cannot guarantee compatibility with > > > other repositories, quoted below for completeness and as food for > > > discussion. The paragraph is unchanged since April 25th, 2003. > > > Since fedora.us started without any packages and there were already a > > number of existing repositories with a good amount of packages. The > > fedora.us policy could have been to work together with existing > > repositories and implement something that could have worked. > > Sorry that I won't participate in going back to very old threads from > fedora-devel@xxxxxxxxx list, which were not fruitful. It's beyond my > time. The list archives are still open. Everybody is free to skim over > the several hundred relevant messages and look at the problem. Okay, I > added my comments in this thread, but that's just because I'm subscribed > to this list. Fair enough. > There are a very few people (or maybe it's just one) who don't realize > that I'm just a contributor. I'm not in charge of the policies and > objectives. I'm not a fedora.us spokesman either. Gah! It's insane to > think that, when I never ever claimed to be a spokesman. Fedora.us > provides a system which allows community commitment, where I, as a member > of the community, can contribute. Other contributors have noticed the > possibility, too. On the contrary, when fedora.us was started, and even > many months later, no other packaging project was ready to accept > community commitment beyond private mails or mailing-lists. That's not really correct, Michael. It may be your believe, but the fact that at the start most of the 3rd party packagers were involved in fedora.us is a clear indication that we believed in a single merged repository in the long run. Most existing packagers finally did not believe in the direction fedora.us was going and the way it mandated exactly how it was proceeding without real input from others outside that inner circle. My experience is that that (and of course that RepositoryMixing document) are the real reasons why most of us were put off. Read that document, go back to the situation 2 years ago and ask yourself why one of us would be interested to join. Ask yourself why one of us would join today ? I think you find more questions than answers. At least if you have listened to our concerns then and now. > An environment, where competition between repositories dominates and > crushes any attempts at working towards a higher common goal, is hostile > instead of beneficial. Do we all have the same goal with extra packages? > No, we don't. Not even with common libraries, I've been told. I understand > that e.g. Matthias Saou didn't want to "give up" freshrpms.net in favour > of maintaining his packages as part of a project that started as "Fedora > Linux". But as could be read on the old fedora-devel list, the other > contributors did not see a way to base their project on packages from an > external repository, packages which are out of their control. That's not true. But tell me why we would leave our working environment behind for something that had not proven to work (better!) or did not even listened to our concerns ? Based on that I can only conclude that it was never fedora.us intention to work together. But that's not really important. The real question is, is there an intention now to find some common ground and loose some of the duplication efforts or not. You have to know that of course Fedora is a too limited view (I've repeated that before on the fedora.us mailinglists too). Our packages work for much more than just Fedora and our userbase is therefor much wider than only Fedora and only i386. This should also be appealing to Red Hat, since having a wide set of extra tools and packages that also work for RHEL will only help in selling Red Hat in a lot of environments. > > > * Users may also have any arbitrary mix of repositories, creating an > > > unsupportable testing nightmare. > > > > Which is only true if you have 5 SPEC files resulting in 5 packages, as I > > said there are other ways to reach the same goal and we've opted to have a > > single SPEC file resulting (if necessary) into 5 packages. The next step > > obviously is to look at why we still need 5 packages and how to merge the > > lot. > > Why not take the route of Fedora Extras and extend Fedora Core with add-on > packages, which to use as foundation for even more packages? A single > easy-to-find place where to get extra packages instead of a multitude of > repositories around the world. A single repository which CD manufacturers > can mirror and burn onto CD/DVD. A single repository which to include and > support directly from within Fedora Core. Why have many 3rd party > repositories, which first extend Fedora Core and then extend eachother? > Why not create Fedora Extras and then add complementry, special purpose > 3rd party repositories, which depend on it? Ah, I think I just answered these questions. Fedora is only a small subset of what we offer and what we hope to offer. We work not only with the Fedora community, but with lots of other communities too, this helps in getting more feedback and more users that can give good feedback. > > I'm sure fedora.us, now that it has packages and is maturing, is working > > at a slower pace than at the beginning. You can't just change direction > > anymore if you have a large userbase. > > IMHO, the situation hasn't changed at all. The total number of package > developers has increased. There are still new submissions added to the > package requests queue. But the general willingness to adhere to the > policies/guidelines and make _utilisable contributions_ (reviews, > approvals, packages which don't fail to build) is still missing. The > interest in getting packages accepted and included is there. But the > willingness to team up with other developers is missing. Ok, I thought it was a compliment if I said fedora.us is maturing, but if you say it isn't, I'm not going to argue with you. :) Let me say that the key to fix what you've just summed up is to have a subversion/CVS in place and make the commits public (or at least public to the packagers). Transparancy is a good way to coherency and to spur discussion to things that really matter. An advice from a fellow packager. Kind regards, -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
