Re: RE:Ad-hoc survey of existing Debian git integration tools
PICCA Frederic-Emmanuel writes ("RE:Ad-hoc survey of existing Debian git
integration tools"):
> It seems to me that Debian should propose a sort of decentralized
> github which should allow upstream to setup within a minute a 'PPA'
> which can be naturally connected and beneficiate of the buildd,
> autopkg-tests depending on the infrastructure shared with other
> etc...
dgit is a step in this direction.
I'm not sure I entirely understand your situation, but:
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.
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.
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.
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.
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)'.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21944.44625.40071.605...@chiark.greenend.org.uk
RE:Ad-hoc survey of existing Debian git integration tools
Hello Ian, Since we are speaking about workflow. I work with instituts who want to maintain internaly their own debian packages and repositories. The objectif is to maintain sort of 'PPA' in order to be as reactive as possible when deploying the code internally. Now from time to time it would be great to release officially these packages without too much pain. So I would like to know how you are envisioning this sort of workflow with dgit ? A way to have a dgit 'instance' repository internally to an instituts and the connection with the dgit repository of Debian. These instituts are also upstream developpers and they want to keep the packaging (debian directory) into their upstream git repository. It is time consuming to maintain in parallele a debian package on alioth and a debian (directory) package in the upstream for the internal purpose of the institut. sometimes we need to fix the upstream source and it is a lot easier to commit to the upstream and do the packaging from there instead of generating a .tar.gz, importing this in a separate alioth repository doing the ususal packaging stuffs (copyright, sbuild, lintian piuparts, etc...). This question also the team working when the packaging is not on the debian infrastructure In fine the question is how do we create easy passerelles between upstream repository and the debian infrastructure. It seems to me that Debian should propose a sort of decentralized github which should allow upstream to setup within a minute a 'PPA' which can be naturally connected and beneficiate of the buildd, autopkg-tests depending on the infrastructure shared with other etc... I franckly speaking do not have an idea of how all this should be organize but I would like to share my tought with you. Cheers Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b217a...@sun-dag3.synchrotron-soleil.fr
