On Mon, 27 Jun 2011, Bryan J Smith wrote: > You've always thought outside-the-box and too far ahead of a lot of people > (and > I say this as the sincerest form of complement). > > I've watched the Fedora Project's evolution over many years and while you > might > have not been a part of the team or list directly, there's no denying your > work > and approaches has indirectly and even directly impacted the project over the > years. I'm not afraid to say that in the least bit if anyone ever asks me, or > makes a statement about DAG, RPMforge, etc... > > I mentioned Guidelines, Maintainer and Governance as a kind of "tri-fecta." > Back to my [counter-] analogy, it's more than just a choice (company) detail. > Different locales are trying to solve the same problems, and often use the > same > guidelines (industry) and sources (companies) as other locales, but the > maintenance and governance differences end up making all the difference. In > other words, I've never seen it as a technical issue.
I think a big difference is the fact that we always preferred (mostly by necessity) to have a few people doing lots of packages, rather then a lot of people doing a few packages. This has the advantage that there's less overhead to packaging and the process is light and flexible. But the downside is that we cannot take on large projects, like compatibility with eg. EPEL. If you consider ATrpms, rpmfusion, and the myriad of other repositories, compatibility with other repositories is a hard proposition, and even tracking changes that may influence compatibility is something a small set of people cannot undertake. I think there are other and better solutions if we want the best experience for our users, but this project has more important concerns than inter-repository compatibility IMO. Compare it to world-peace or world-hunger, how much I like this to happen, I am afraid I won't be able to make a big contribution to the overal solution. Larger entities might have more impact than myself. So I support where we can make a difference with little effort, but a larger solution is probably out of our reach :-/ Unless of course we rethink everything... -- -- dag wieers, [email protected], http://dag.wieers.com/ -- dagit linux solutions, [email protected], http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] _______________________________________________ users mailing list [email protected] http://lists.repoforge.org/mailman/listinfo/users
