Shared pidgin releases and vcs-pkg

[Felipe Contreras]

On Mon, May 25, 2009 at 12:35 AM, Richard Laager <rlaager at 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