Fedora Tracker: Part Deux

[Jef Spaleta]

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