RFR: GIT Package VCS

[Christopher Blizzard]

On Wed, 2007-06-06 at 16:16 -0400, Jeremy Katz wrote:
> 
> The problem with a staged approach like this two-fold
> 1) Moving off of CVS is going to end up requiring a fair bit of
> relearning/retraining for people.  Even if we keep the workflow the
> same.  So by having it as a two-step thing, people have to retrain
> themselves _twice_ rather than just once.
> 2) If you let some people move and not others, then it becomes very
> difficult to know what you have to do to make changes to a specific
> package.  If you're the only person that works on something, that's
> not
> such a big deal... but we want to be encouraging collaboration and
> working together.  Having two different ways of doing that at the same
> time is going to mean that everyone has to get over the hump _anyway_.
> So why not just take our lumps in get there in a go. 

So regarding 1. I would suggest that we leave "classic" packages in CVS.
Learning another system is a big deal and we get almost no bang for that
buck so I don't see us moving off of CVS for our current repo setup any
time soon.

I think that moving selectively is the option of the developer and/or
maintainer and should reflect how the upstream project works.  And it's
only really required for stuff that's moving quickly or has a large
community.  Remember one of our primary goals: get as close to upstream
as possible.  If we're supporting them by using the same DVCS then they
are more likely to assist us, not to mention how easy it gets to figure
out what's different between repo a and repo b.

For example for the kernel, we might want to pull from a git repo.  For
people who use hg, we just use that.  For projects that just release
tarballs, we stick with what we have.

This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?)  Well, yes,
until you realize what you need to do here.  To start with you only have
to teach the rpm build side how pull a specific tag from a specific
repo.  On the query side we need a browser for each kind, which is a bit
of work, but something I think we need to do anyway.  (i.e. "What would
git do?")

Plus, to be honest, it completely avoids the whole "which damn system do
we use."  And I like focusing on the end user features instead of
getting stuck in VCS dicussion hell.  We're not going to get everyone
else to agree or even use the same system.  So let's build something
that supports both.

I understand the training costs here, but to be honest I think that
local experts will continue to be local experts.  And we want more of
that not less.

--Chris