Fedora Tracker: Part Deux

[Matt H]

On Wed, 2004-03-30 at 10:37:12 -0500, Jef Spaleta wrote:
> 
> ______________________________________________________________________
> 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.

Yes, this anti-correlation is a shame for such a useful, needed
functionality.  You are correct with your interpretation of my post; I
indeed would like to see a http://fedora.redhat.com/projects/tracker
page for this project.  

> 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.   

Now, what ways can these legalities be dealt with to keep in line with
The Fedora Project's objectives? The underlying infrastructure is fine
as you mentioned, the issue is the with the content this infrastructure
interacts.  I may be totally off-track here, but hosting a development
platform surely is different than hosting an implementation?  Could this
not be the case for The Fedora Tracker Project?  If we control what is
indexed, then development could continue as part of a Fedora
sub-project.  i.e. fedora.redhat.com could implement a
DMCA/Fedora-compliant implementation (albeit limited), while Brad's full
version could be hosted elsewhere.  This probably defeats the purpose of
Brad's goals for the Tracker however and wouldn't be very practical.. 
  
> > 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.

This statement, unfortunately, proves that my idea above is more of a
pipe dream. :( Even if a DMCA/Fedora-compliant implementation were
possible, it could never be as functional as it should be; - "bridge the
gaps, not throw up barriers"..

Regards,
-Matt
-- 
Registered Linux User #348963 / counter.li.org
GnuPG KeyID: 0xCE9F8922 / gnupg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040331/d37fc937/attachment.sig>