[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Hosting repos that are not upstream



On Wed, 2007-08-01 at 19:15 -0400, seth vidal wrote:
> On Wed, 2007-08-01 at 12:21 -0400, Christopher Blizzard wrote:
> 
> > It's really not about forking.  It's about allowing for easy
> > experimentation which encourages developers to work with Fedora.
> > Everyone has used repos forever.  But repos aren't connected to any
> > particular development branch.  (i.e. here's a repo, but where's the
> > development happening?  Who is involved?  Is it still active?) 
> 
> Yes, and that results in these nasty little abandoned forks that we
> can't purge off the system and we end up lugging around FOREVER. Ever
> looked around elvis? My idea of hell. You've got to remember that your
> project utopia requires real resources. Real resources that are actually
> scarce when we have to maintain them for N years.
> 
> >  Also it would seem that keeping the knowledge of changes involved in a
> > particular development effort is important.
> 
> Keeping the knowledge of any random fork? If a contributor comes to us
> and asks for us to add a hosted repo in place that's just a cvsimport or
> an hgimport of a project that already has an upstream and just isn't
> using someone's favorite SCM, should we host it then? It's just a
> convenience repo. What good does that do anyone to have it sucking up
> system space instead of just sitting in someone's public_html dir on
> fedorapeople?
> 
Ubuntu is doing this kind of thing with a single SCM (bzr) and
launchpad.  I have first hand experience saying this is both useful and
a pain in the neck.  As a developer, you get a branch on which you can
commit changes and merge to all the other branches that are registered
on the system.  That's pretty cool.

As a packager, there are times when you're wandering through a forest of
branches not knowing what to pick.  launchpad can mark a single branch
of the code as canonical (a mirror of upstream, that of the main dev
team, the packager's tree, etc) but if no branches are marked, then you
just have a bunch of forks without an indication of which you should be
using.

As a system admin I have the same reaction about resources as Seth but I
don't know if I'm right to think that way.  Contacting some Ubuntu sys
admins about their setup and costs could be useful.

In my view, just throwing random mirrors/forks of upstream into our
infrastructure is not good.  We have to have some method of showing why
the branches exist to make it useful.

-Toshio

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]