Matej Cepl wrote:
Uhm.... Matej, please don't speak for the rest of us. The main reason that we haven't switched to a DVCS is that none of the people who implements things for infrastructure wants to step on the toes of people who believe that a different DVCS is the way to go. git, hg, svn, and bzr were all proof-of-concepts but none of them were able to reach a critical mass of support vs hate.Take a look at the bottom of http://fedoraproject.org/wiki/Infrastructure/VersionControl/ArchitectureDraft -- it has been last updated on 2006-07-23. That's ancient history in the fast flowing Fedora world. In the last year or so I have never ever heard anybody mention other DVCS than git. Aside from bzr coming from THEM :-), there is such overwhelming majority of git users over anybody else, that nothing else than git is just not an option for distributed VCS.There are periodically flamewars about switching our packaging to DVCS (hell, I would be glad if we use at least CVS correctly), but usually there are good reasons why it is rejected. See for example http://thread.gmane.org/gmane.linux.redhat.fedora.devel/68551/ and http://thread.gmane.org/gmane.linux.redhat.fedora.devel/56870/ or http://thread.gmane.org/gmane.linux.redhat.fedora.devel/48106/ for examples of such flamewars. However, people are still working around this (and yes, I know personally about many many people inside of Red Hat who use git-cvsimport for their own packages) -- see http://article.gmane.org/gmane.linux.redhat.fedora.devel/71048
However, madduck does have a few inaccuracies in his blog post[1]_. In order of appearance rather than importance: * The tarball is not downloaded from the source URL when building the SRPM. We upload the tarballs to a lookaside cache before checking in a new version of the package. That way we aren't at the mercy of upstream changing locations or disappearing entirely. * The ArchitectureDraft proposal is one of many potential ways that were explored to do this. So even though it's a writeup of bzr, the things that have been tried has spanned most of the current major vcs's (darcs being the one exception due to it's not meeting our requirements for keeping history intact.) * My understanding is that Debian packages reach the repo by way of a trusted contributor building the package and uploading to the master server. In Fedora all changes are checked into VCS and then the buildsystem pulls the files from there and builds the packages. So the VCS usage in Fedora has a centralized hub in the form of the buildsystem.
I do think that madduck has nailed one of the problems with switching to a new version control system for Fedora although the knowledge doesn't mean as much to him as it does to us (because Debian's current VCS usage is much different than ours). Contributors are never going to agree on one true VCS for our needs but we need to have a centralized repo for the buildsystem. For us to get critical mass to migrate is near impossible.
P.S.: madduck, I like your categorization of changes although I think we'll have to make it feel less complicated for the end-user packager to adopt. Solving the patch dependencies is the truly hard part of that problem as everything I've looked at has either made constructing the dependencies or the application to the vanilla source hard.
.. _[1]: http://madduck.net/blog/2008.01.29:consolidating-packaging-workflows-across-distros/
-Toshio
signature.asc
Description: OpenPGP digital signature
_______________________________________________ vcs-pkg mailing list vcs-pkg@lists.madduck.net http://lists.madduck.net/listinfo/vcs-pkg
