Brad Smith wrote: > This assumes that Tracker is going to be integrated into > Fedora.org. As nice an ego-stroke as that would be for me, the very > reasons you point out would seem to make keeping it as separate an > entity as possible a good idea. I think perhaps you misinterpreted what I was trying to say. Or perhaps the fever I had yesterday affected my ability to communicate. Looking back today at what Matt H. wrote, its pretty clear my feverish state was affecting my comprehension. Matt H. was actually talking about turning the tracker into a subproject of Fedora, to give it a homebase for its development effort not necessarily incorporating it into the main site's functionality, which is how i originally read it yesterday. My main point being, as things stand, the potential usefulness of an implementation of the tracker is anti-correlated to its potential integration into official fedoraium functionality. Once fedora extras opens up for contributors to use, i don't see any obvious problem with trying to use whatever hosting services Red Hat eventually provides for contributors who have new community initiated fedora related projects. We'll have to wait and see how things develop on that front. There's nothing inherently problematic with the tracker codebase really, the problems are very much associated with building the repo index. While the codebase itself might fit into an expanded idea of a community development model, any really useful implementation of this out in the wild has to be totally independent. Though, there could be some people like .edu's who might want to use something like the tracker in their intranet. If the fedora project does host web pages aimed at development of the tracker your still going to run into trouble trying to provide links from those development pages to a fully indexed demo. > On the other, this opens up a whole set of issues, not just of > determining an appropriate policy, but of enforcing said policy without > making it prohibitively difficult to be indexed. As much as I support > the standardization of QA practices etc between repos, Tracker's job is > to help bridge the gaps between repos, not throw up barriers to > inclusion. Personally i think yer going to find that job description is going to become rather cumbersome if the number of repositories you index grows to 100+ repos. I think you will find that, for a tracker to stay useful as its popularity increases, there is going to have to be continual human effort,editorial effort, to evaluate the worth of the listing of individual repositories in the index. I think anyone managing a popular implementation of the tracker, is going to have to develop some policy with regard to what is and what is not indexed, if the point is to provide users with a useful tool. Do you really want to list all the possible repos? Even if that means 100 different repositories that provide binary kernels with different modules turned off or on or compiled in? Shall we index all the 4 package people.redhat.com micro-repositories? -jef"how much fun would it be if all the projects building RPMs in the st.net ftp trees decided to build individual yum repo and wanted to be listed with the index..1000 or so indexed repositories would be...interesting"spaleta
