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
