Our SCM

[seth vidal]

On Wed, 2007-06-20 at 15:15 -0400, Christopher Blizzard wrote:
> On Wed, 2007-06-20 at 11:22 -0700, Karsten Wade wrote:
> > 

> Right!  So here's another question for you: how do we make things
> easier?  And I don't mean just getting the model right (i.e. DVCS as a
> mechanism) but also keeping things super-easy to use?
> 
> Here's a completely crazy idea: do an "online" translation activity that
> uses google gears on the backend that lets people do their work offline
> and then can sync up when it's done?  That way anyone on
> linux/windows/mac can participate and they can get hooked directly up to
> web services we have in place?
> 
> That's outside of our comfort zone, but it's not completely crazy.  Our
> work has to be about enabling people so that working with us and the
> rest of the open source community is easy easy easy.

I was thinking about this subject this week. All the ideas I've heard,
thus far, for how to achieve the above involve fedora having nearly
limitless resources for people to use in terms of bandwidth/disk
space/etc. They focus on developers coming to work on our systems with
us. My problem is that it seems to scale less well b/c we're essentially
creating a monstrous silo that we are inviting any and everyone to come
play in. I think we've had that before, it was called sourceforge. It
sucks resources and is a pain to maintain.  However, I do like the
objective but the implementations I've heard so far don't fill me with
joy.

So I was wondering if it might be possible to reverse the model a bit.
Why not make it so our buildsys and related pieces can easily pull from
upstream's scm's.

so we don't keep an infinite number of copies of upstream internally
and/or end up with special forks.

Now, the bad parts of this are fairly obvious:
 - we rely on the consistency of upstream (which we do already, we just
delude ourselves into thinking that somehow the vcs checkout or the
tarball is more consistent)

I'd suggest something like this:
 1. where upstream is willing to play ball, we ask them to setup a
fedora branch/subdir in their dvcs repo that points to our git/hg tree. 

 2. when not possible we use our own vcs for that data and we offer to:
    a. work upstream if they want
    b. grant them access to work out of our vcs in the same was as in
[1], just reversed.

This way upstream can retain as much control as possible  w/o us having
to have an infinite fork of everything in every upstream project.

Does that make any sense at all?

-sv