Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Mon, Nov 17, 2014 at 11:39:10PM +0000, Simon McVittie wrote:
> On 17/11/14 16:24, Ian Jackson wrote:
> > I don't think this problem, of a mass of different branch structures,
> > is going to go away any time soon. Simply because people don't seem
> > able to agree.
I agree it's unlikely to go away, but I do also think that if the reason
this is the reality we have to work with were actually as simple as a
lack of consensus on how to name them, then it would have already gone
away a long time ago.
git didn't make branching such a powerful and central part of its
paradigm just because chaos is fun. It's because it accurately
describes the reality of the topology that forms naturally as soon
as you decentralise version control, and allow truly distributed
development, where every clone is a first class entity in its own
view of the set.
> > My answer is to create a parallel universe in which the branch
> > structure is known.
>
> As far as I can see, in effect, Kali's answer can be described by the
> same sentence, except that Kali's parallel universe doesn't have the
> same known branch structure you do, presumably because Raphael's
> preferences are different; Kali's known branch structure is "what
> git-import-dsc does" whereas yours is based on what "dpkg-source -x"
> produces, resulting in different trees in the repository for 3.0 (quilt)
> packages.
Right, and there are lots of other tools that do exactly this too.
git-debimport from gitpkg does the same thing from the history of
existing packages, and Marco wrote and published one that did this
job for the packages he imported to git from other forms too, just
to name two. The basic structure of all those is almost certainly
congruent, but in addition to the problem that Simon points out,
they're still limited to only dealing with a simple linear history.
Which isn't at all the reality of really working in git for anything
but the most simple and parochial of packages.
As soon as you have backports, or stable updates, or tweaks for some
other distro flavour, or multiple developers working on individual
new features, or WIP branches that aren't ready for release yet but
might contain some useful thing already ... chaos has laid its egg
in your nest. And you can either incubate it lovingly, or get it
on your face :) What you can't do is avoid it.
I think we're still quite some way from having everyone on the same
page about how to embrace that and empower downstream developers
with it. There's certainly far too many permutations to robotically
name them all (and their relationships to each other) in any kind of
rigorously meaningful way. But I think that this is the problem
which, if we "solve" it, will actually get us on the path for some
sort of sustainable collaboration, that doesn't require incompatible
forks as some sort of creole to roughly paste things together.
At the risk of opening another somewhat partisan question here, the
common elephant that does appear to be taking shape in the room here,
for all the currently existing tools, _is_ actually the problems
created by format 3. Which makes me wonder if addressing those as
a first priority, isn't actually the best thing that we could really
be looking at first here, rather than looking at what complicated
things we might do to sort of work around them in some cases ...
> > The maintainers of each package choose whether to use the dgit
> > `universe', in which case certain basic assumptions can be relied
> > on, or run their own `universe' in which case they can structure
> > it however they like.
Is there somewhere I can clone a dgit'ified package repo from,
using the normal git tools, to have a look at it - or do I need
to drink the whole jug of kool-aid to be able to do that?
I am curious about how its 'universe' maps to packages that
aren't strictly linear because there have been backports or
security uploads, or other stable updates, or minor changes
to suit some other distro release etc.
Cheers,
Ron
Reply to: