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


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