On Mon, May 25, 2009 at 12:35 AM, Richard Laager <rlaa...@wiktel.com> wrote: > On Sun, 2009-05-24 at 14:13 +0300, Felipe Contreras wrote: >> Optionally, each package maintainer can push their patches to >> this repository so that other people can easily fetch them, and >> perhaps even share patches between distributions! > > This is an interesting idea. There was talk at UDSJaunty of Ubuntu > wanting to do this distro-wide. Of course, they'd want to use BZR. > > Some downsides and points for discussion: > > 1) Competing DVCSes. Unless everyone is using the same one or you have > really good tools that can keep multiple different repositories in sync, > a lot of the benefits are lost.
>From what I have seem git is the most widely used: http://git.debian.org/ http://git.fedoraproject.org/ http://git.opensuse.org/ So it makes sense to use it. Also, git->bzr and git->hg tools work pretty well. > 2) In Ubuntu's case, it's more useful if Debian is doing it first. Given > that's not likely to happen for every project, they were talking about > needing support in BZR for splicing stuff into the previous history as > upstream and/or Debian get on board. If this happens, issue #1 makes it > even worse. No DVCS deals with this case right now. Splicing in stuff > would generally change all the revision IDs. I'm not sure what you mean by splicing, but it sounds like git graft points: http://git-scm.org/gitwiki/GraftPoint > 3) You already pointed this one out: >> Also, I guess some maintainers might want the tarball contents as >> opposed to the versioned files, that could also be versioned in the >> same repo. > > The right way here, I think, is to have your releases branch come off of > trunk. Assuming you started at 2.5.5, as an example: The 2.5.5 > tag/revision on the releases branch would be a child of the 2.5.5 tag on > trunk, minus files we don't distribute, plus the generated files. Then > 2.5.6 would be a merge between 2.5.5 on the releases branch and 2.5.6 on > trunk. As far as the contents go, it would be equal to 2.5.6 on trunk, > minus files we don't distribute, plus the generated files for 2.5.6. Yeah, if you need releases that's the way to go I think. A piece of cake to do in git. > 4) Is this really useful? Why aren't tarballs enough? I think defining > some concrete use cases would be the best way to start designing such a > setup. How about these: * Upstream makes a new release and the patches need to be rebased on top of it * Upstream makes a new release and some commits need to be backported to a maintainance branch * A vulnerability is found and another distro already made a release with a patch, you want it too Another advantage is that similar distros (ubuntu-debian, fedora-opensuse) can share most of the packaging stuff (.spec, debian/*). > 5) Do we really want to encourage direct sharing of patches between > distros? Wouldn't we want to get them upstream ASAP if they're useful > and cut a new release? Yes, that would be ideal, but in my experience upstream does not make that easy. -- Felipe Contreras _______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss