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.
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.
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.
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
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?
ubuntu-devel mailing list
Modify settings or unsubscribe at: