Eric S. Raymond wrote:
These both seem like readily solvable problems to me.
I'm of the opinion that some issues are complex enough to allow for perfectly valid and completely opposite points of view. And I'm also of the opinion that some issues are dominated more by historical precedent and "i was here first, automatically respect my claim on mindshare in this space" attitudes than on sound logic and a willingness to compromise on arguable less important priorities to meet the most important priorities. And I'm of the opinion that sometimes people just can not agree on what the priorities are.
So lets get down to to it shall we? Let's look at the history of the repository space. Red Hat, in the past, for reasons of their own, have neglected to foster any sort of policy or guidelines about how 3rd party repositories should be structured. As a result what sprang up has been a very fractured collection of one person or very small group efforts to provide a needed community service to provide additional packages to the userbase. Some have become quite popular and to their credit became popular because they did indeed have a measure of quality in their packaging that the userbase grew to respect..but the fact is, it was a very fractured landscape, leading to real package conflict problems across repositories, and end-user difficulties when trying to reach out and get all the packages they wanted, from multiple repos. I would describe the situation as loosely related bands of nomadic tribes of packages. Sometimes their were inter-tribal marriages and sometimes there where blood feuds.
I'm not going to take anything away from someone who is able to build 500 packages and place them into a repository and build a userbase. That is an accomplishment of merit. But its not a community effort. 2 such people who have the ability to build their own 500 package repository as they see fit is not a community...neither is 5 or 10 or 20 or 40 or 17 billion. A community effort MUST have guidelines and policies to follow and their MUST be peer review, and a sense that interested people can walk into the process and learn how to be active in it, a way to mentor such people and teach them how to do things in the best ways following best practices and a sense that they can earn a place in the process. There needs to be a sense that if one person steps out of the process for whatever reason the community effort will continue. There must be a sense that everyone involved is valued...but not indispensable. An archipelago of one man repositories doesn't really convey this sort of sense of community. If for some reason, god forbid, Dag had to stop producing packages for personal reasons, that's a big blow to the archipelago concept since there are no written policies that I know of that others can follow to reproduce what he has accomplished.
I'm not a scholar of the history, but the first noteworthy example I noticed of defining ANY packaging and QA standard for Red Hat rpm repos was fedora.us. It's pretty clear to me that fedora.us policy that we see now, has prioritized around the concept of building an actual community process that in the long run can be reproduced and re-implemented from the written policy guidelines....and not from a cult of personality.
And now we come to the crux of the issue. Coming to a consensus among ALL the interested parties about what the actually priorities are in the process pretty much defines what the packaging community is going to look like: How transparent do the QA processes NEED to be? How much input from the community does there NEED to be? How hard do you want to try to make sure all the packages meet the same level of quality? How important is it to make sure all the packagers are using common conventions and best practices when writing build scripts?
And i see the current split in the world views as coming down to prioritizing the first couple of questions in the list. Fedora.us ranks transparent QA and the NEED (not just a token desire) for community input on how packages are built very highly. I don't see the one man repository islands making these things a priority. And thus, the discussion can not get past that split in world views. If people in the discussion can not agree on the priorities...there is a clear difference of opinion at the basic level of belief at how the world is suppose to work. Pretending that you can get people who have VASTLY different priorities to come together for a consensus is a foolish naive dream. I'm pretty sure its been stated already somewhere in the fedora lists, that there was internal Red Hat debate about joining debian, but because the list of priorities as Red Hat understood them differed significantly from the priorities debian has...we have the Fedora effort instead.
And in a not so dissimilar way, we stand now with 2 opposing view about what community packaging should look like. The pre-existing archipelago of one made repos loosely working together with community input welcome but not really necessarily. And the 'new' concept of fedora.us which places a HIGH value on making community involvement as part of the packaging process a priority. Different world views....and i would strongly argue that a continued refinement of how fedora.us tries to do things is in the long run the stronger more robust community process. A process that not only creates high quality packages, but provides a clear way for new and interested community participants to get engaged and invovled and to mentor them so they learn via communication with other community members how to do packaging better. It provides strong lines of communication so that best practices in regard to how to package things are not horded by the 'professionals' as a secret sauce knowledge but focuses instead of making it possible to document those best practices so that new people can learn them.
Is there room for improvement on how the fedora.us policies work... of course. But to make constructive forward looking changes to the process, you have to value the core objectives that the fedora.us process is trying to meet. And in my mind the core objective for the fedora.us process is not to package up the world as quickly as possible...the focus is on building and documenting a community process for building high quality packages that other people can follow and use as a guideline. And I personally think if the new Fedora Extras process doesn't continue to make transparent QA a priority...and doesn't continue to demand community involvement as part of the packaging process, but instead allows 'trusted' packagers to do whatever they want without peer review....the overall Fedora effort will be losing a very good process for educating and mentoring NEW community members who want to get involved with packaging. A community process NEEDS to be as much about educating and mentoring NEW community members so they can continue on with the work..as it is producing a work at all.
-jef"and that was me trying to be nice..."spaleta