Hosting repos that are not upstream

[Stephen John Smoogen]

On 8/1/07, Christopher Blizzard <blizzard at redhat.com> wrote:
> On Wed, 2007-08-01 at 11:53 -0400, seth vidal wrote:
> > On Wed, 2007-08-01 at 11:42 -0400, Christopher Blizzard wrote:
> > > On Wed, 2007-08-01 at 11:42 -0400, Jesse Keating wrote:
> > > >
> > > > Collaboration between more than 1 or 2 people on a patch set to
> > > > propose
> > > > upstream.
> > >
> > > Yeah, this is what I've been pushing for forever.  "Private Builds".
> > > The use case is something like project utopia.  Where you have to make a
> > > pile of builds together in order to make some change and you want to
> > > work with and collaborate with other people outside of the mainstream of
> > > development.  Doing so should be the click of one button.  Once again,
> > > it's about attracting developers, not really about having only one way
> > > of doing things.  And developers like to work with other people and have
> > > a convenient place to do so.
> > >
> >
> > OR to rephrase what you've just said:
> >
> >  it's about maintaining forks and encouraging forking.
> >
> > If we setup a new repo at hosted, everytime someone wants to play with
> > something we'll have an infinite set of repos and we'll have a lot of
> > languishing and abandoned branches that never get cleaned up.
> >
> > Making a repo at fedorapeople.org is trivial and available and it
> > doesn't require any intervention by people in the infrastructure group.
> > Just drop your repo there and go!
>
> 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?)  Also it
> would seem that keeping the knowledge of changes involved in a
> particular development effort is important.
>
> There are a lot of languishing and abandoned repos that exist out there,
> too.  They just take up a lot more space because they include source +
> binaries, not just a pointed to a starting point + a set of patches.  :P
>

Before this conversation goes on any further.. could we get both
people's definition of a fork? My take on it is that you are both
using a word with completely different ideas of what it is.

One definition of a fork would be that every distributed git
collection is a fork of the 'master' version Linus uses. Another is
that a fork would be if I called my git collection Dominatux and would
be working on that as the bound and gagged penguin kernel.




-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"