Re: RE:RE:Ad-hoc survey of existing Debian git integration tools
PICCA Frederic-Emmanuel writes ("RE:RE:Ad-hoc survey of existing Debian git integration tools"):
> > dgit is a step in this direction.
>
> Yes and it is nice to have meta data (the dgit things) rerpresenting
> the packages which can be shared between derivatives.
I don't understand what you are referring to here.
> > If you are a downstream, there is no need at all for you to generate
> > and work with source packages. Instead, you could keep your source
> > code entirely in git, and build binaries directly out of git clones.
>
> Yes but if peoples are using autotools they do not necessarely put
> all the autogenerated files in the git repository. so if you want
> at the end to set up some intégration branch where all the
> autogenerated files are integrated.
Are you saying that your source packages contain things that your git
repositories don't ? This comes up occasionally, and I will say again
what I have said before: I think this is wrong.
You should have a single notion of `source code'. To borrow from the
GPL: the source code is the preferred form for modification.
Either the file (`configure', say) is part of your source code, in
which case it should be in the source package and in the git
repository; or it is not, in which case it should be absent from both.
> or maybe this sort of bootstrapping should be part of the build
> process, or the job of the get-orig-source make target ?
If you think the source code does not include `configure', then
building from source includes regenerating it from `configure.ac' or
whatever.
Conversely if you think the source code includes `configure', then
building from source does not include regenerating it, merely running
it.
> > If want to do this, the dgit view of the Debian archive is a good
> > starting point, because it is a uniform view of the archive: a git
> > branch containing an editable, buildable package.
>
> So we need to agreed on a convention in order to let the upstream do the job of integrating their work in the Debian archive.
> Or at least to prepare something which could integrate the Debian archive in the end.
I don't understand.
> > If you find that you want to edit the upstream source, you can make
> > your changes on an upstream git branch, and then merge or cherry pick
> > that into your packaging branch.
>
> Does it mean that the dgit repo will contain also the upstream repository ?
In git terminology, the tree objects in the dgit view contain the
upstream source code.
The commit objects do not necessarily have as parents any particular
upstream git commits. Indeed, the first time `dgit fetch' is used on
a package never uploaded with dgit, the commit objects generated by
dgit have no external ancestors.
So dgit provides a standardised _tree_. It does not impose any
structure on the _commit graph_, except to insist that the dgit view
of any particular suite is fast-forwarding.
For a package whose maintainer is using dgit, it is the maintainer who
should be choosing the commit graph structure, and the contents of
commits other than the tip of the dgit suite branch.
> > If you want to feed your changes back to Debian, you need to provide
> > the maintainer with the format that they are expecting. If the
> > maintainer is using git, a git branch (with reasonably clean history)
> > is probably a good bet, but you should ask the maintainer.
>
> dgit should propose a sort of PR (via email) in order for the
> upstream to propose the integration of its prepared package into the
> repository. something which is done for now via mentors, maybe
I don't understand.
> does dgit propose to intégrate also the pacakges on mentors
I think you mean `are packages on mentors.d.n visible to dgit'.
The answer to that is `no they currently are not'.
The main part which is missing there is a git server suitable for this
use, but also the mentors workflow is rather unusual, because packages
uploaded to mentors.d.n are not in a suite in the same way as packages
in the archive.
It might be possible to in principle for dgit to present a view of
mentors. But, I wonder if that would be a waste of time. It would be
much simpler for the mentors and mentees to simply exchange git
branches and not bother with source packages at all.
The git branches could easily live on alioth (less of a security
problem than having the dgit repos on alioth, since the sponsor is
going to double-check them anyway).
I don't know what mentors and mentees would think of that.
mentors.d.n would need a way to represent a git-based sponsorship
request.
> > If you are the maintainer, then you can simply dgit push into Debian
> > from your packaging branch. If you have made the git history
> > complicated (eg, with merges), you may need to either linearise it
> > somehow yourself, or simply switch away from `3.0 (quilt)'.
>
> I do not understand this part why a non linear history is a problem
> for dgit ?
If you are the maintainer of the package in Debian, and you are using
source format `3.0 (quilt)', then you have implicitly committed to
maintaining your package as a linear sequence of patches on top of
upstream. Merging from upstream branches in your git history is not
consistent with that.
Ian.
Reply to: