Moving this to fedora-devel and changing the subject for wider discussion. On Wed, 2007-06-06 at 16:53 -0400, Christopher Blizzard wrote: > 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 would agree except that CVS is such a crappy SCM. While I've been converting the existing CVS repos to Git for some testing I've seen evidence that some of the CVS repositories contain some corruption. It could be that what I'm really seeing are bugs in my conversion tools or that someone manipulated the CVS repositories manually in a non-kosher fashion. However, CVS the fact remains that CVS is a very bad SCM and I don't want to deal with it more than I have to. The only thing that CVS has going for it is that people seem to have infinite amounts of willingness to put up with it's foibles. That being said, I won't put up too much of a fight if in the near future I can move the packages that I maintain to something other than CVS. > 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 think that's a great idea... Even the best tools won't convert repositories perfectly. And using the same SCM as the upstream makes it a lot easier to communicate changes with the upstream developers. I do think that we need to limit the choice of SCM to ones that support a distributed style of operation and to which Koji has been taught to build from (I think that Git and Mercurial stand out as obvious first targets). Jeff
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
