On Tue, 30 Nov 2004 12:51:08 -0500, William M. Quarles <quarlewm@xxxxxxx> wrote: > And the repositories don't all compete with each other. That's only how > Fedora Extras sees it, because THEY are the newcomers trying to compete > with all of the other repositories. I use the term compete.. in a larger sense then you do. I look at any duplication of effort, to package the same packages in different locations as competition for manpower. I believe the entire process is manpower limited, and I believe it is wise to reduce the amount of manpower used on inter-repo regression testing and use it for other things. Disagreements at this level come down to priorities, resource allocation and priorities. While there is always a place for divergence and duplicated effort.. as a generator for innovation and experimentation. I see no reason to spend the man-power to encourage a mainline process that makes duplication of effort as central approach to mainstream package distribution and maintaince. And please, you need to understand this is no longer a fedora.us against the repository establishment. Red Hat made a decision to merge fedora.us into the larger Fedora project. Red Hat is not a newcomer to the issue of packaging. We must not look at this from a territorial perspective, this is about making policy that best benefits the project long term. What you see as "new comer" symdrome.. i see as growth of a older distribution to encompass a larger mission. Can it be a bad thing that the distributing is growing to encompass more functionality? You can either agree that centralization is a good thing and will use your limited resources and your limited time to move towards that direction. Or you will disagree with centralization and will work against it. I personally choose to work towards centralization, and find the cost of inter-repo regression testing to be a poor use of limited time and limited manpower resources. Everything has an opportunity cost, and I would much rather see Core and Extras developers concetrating there limited time and limited resources on working inside a centralized non-overlapping buildsystem than having to try to keep up with 5 or 10 or 15 variations of conflicting packages from a variety of locations. I don't even expect Core and Extras developers to have to be concerned with Fedora Alternatives when Alternatives walks out of the vapor somewhere down the line. > A lot of the non-Fedora-Extras > repositories are interoperable now because the individual maintainers > have been working together on that. And they have their priorities... to them.. doing this makes a lot of sense because of the constraints and priorities from their perspective based on their history. Red Hat on the other hand has a longer history and a different perspective... and have chosen to merge with fedora.us into the larger Fedora project. > That has been emphasized several > times already on and off of this thread. I think that it was either > Axel or Dag that said that the repository world has been broken down now > into only two camps, not 4, not 3, only two: Fedora.us, and non-Fedora.us. That is their opinion, and i think they are very good at choosing language that makes them out to be the victim in a personal way. I don't think these sorts of comments are constructive and it greatly dimishes the level of discourse. We must move beyond "us versus them" mentalities. I dont think its useful to talk about "repositories" when counting heads in this fashion. I think its useful to talk about the number of human packagers. Again I believe that the process is in general manpower limited. A centralized...common buildsystem model.. scales to many humans much better than the.. small group of humans per repository model. Its a matter of economics of scale. And I also believe that centralization makes it much easier to keep the communication flowing from users..to packagers...to developers. I believe it will be much easier for upstream developers to become more involved with distribution level bugreporting and fixing if there is centralization of packages for the specific distribution. I also believe that centralized model lowers the bar for all potential packagers who enter the community in all future times. A centralized model, established and makes avaliable a set of common best practise tools and build system to ALL new packagers who enter the system. The centralized model provides inherent mechanism for mentoring. The small group model on the other hand raises the bar for all new packagers who need to not only learn best practises on their own but must build their own build system and distribution infrastructure for their own repository, and then must build their own repository brandname in the community competing for mindshare with established repositories. The issues surrounding brand identification alone probably limit the number of repositories in this model to something like 15 or 20 "popular" locations, before the community is unable to keep up with all of them in a meaningful way. > A volunteer would still have to come forward to keep maintaining that > particular package however. I'm sure that far from all of the packages > will be popular to maintain. You skirt my main point.... it its absolutely much easier for a volunteer to come forward.. if there is a pool of packagers who understand the build system being used for the now unmaintained packages. When you have different repositories....you have different build systems. You lower the bar greatly to a new maintainer if the new maintainer is already building packages on the same build system as the unmaintained packages. The more packagers using the same tools.. the more packagers who are qualified to volunteer. The process is manpower limited... creating a system and a process.. that makes it easy for a package to switch ownership to another maintainer fluidly is an important step in making sure manpower is being used effectively. I believe making inter-repository regression testing a priority is a waste of manpower that can be used for other more important things. > I don't completely disagree with that. I just think that their should > be some centralization, mainly libraries, and also programs that are > useful mainly because a lot of other programs use them. These would be > packages that would not be relevant to Core but would be relevant to > programs outside of core. And leave open some "third-party" > communication. No one is preventing anyone from doing whatever third-party communication they want to do as individual packagers. But we are talking about specific policy statements... and i see no reason to mandate that all packagers in Core and Extras make the effort to regression test with outside repositories as a matter of policy. In fact, i believe such testing is a waste of limited resources that could be used for other purposes. -jef
