(Reposting this reply here too... must stop the discussion on the other list :-) 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 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. At the same time, I think we still need to be able to very clearly separate out our changes from what upstream has. Just a git repo of the kernel very quickly gets out of control and you end up with bazillions of things that you never push back upstream because it's easier to just keep sitting on them. So I don't think that just a VCS repo of the source is what we want... we're going to end up wanting some integration with something quilt-like to get patches out; so like stgit or mq or ... > 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?") So if I am the owner of the rpm package which has an upstream of hg and want to fix, test and commit a change to say (for the sake of argument) neon which is in git, I now have to know two different systems? You're crazy ;-) To add to the craziness of this path, think about actually maintaining these packages across different distro releases... every VCS has its own unique and specially crack-ridden way of handling branching. Or when you star to think about the "I'm a downstream of Fedora and need to change X, Y, and Z" and you are then having them set up potentially 3 different VCS systems to do so. Or the "it's time for a mass-rebuild; let's go and commit a version bump to all the packages so we can rebuild. Uhhm. Uh-oh. > 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. So instead of picking _one_ answer, we now have to make sure that we implement all of the end user features for N systems? Seriously, this is losing. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
