No subject

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