Re: Discussion on eventual transition away from source packages
On 21/03/19 at 16:52 +0000, Ian Jackson wrote:
> Joerg Jaspert writes ("Re: Questions about "Winding down my Debian involvement""):
> > On 15348 March 1977, Sean Whitton wrote:
> > > I won't write a long reply because it's not that important to the DPL
> > > election, but I did want to note that `dgit push-source` has answers for
> > > everything you've listed. I'd encourage you to take a(nother) look!
> >
> > Do those answers only apply if you still think of the traditional source
> > archives to upload, or also if one envisions to go away from that?
>
> If we were to abolish the part about uploading traditional source
> packages, what remains of `dgit push-source' is simply pushing a
> signed git tag with a conventional name to a designated server, and of
> course pushing the corresponding commits to a designated git branch.
>
> (There is a dgit-infrastructure package which knows how to verify
> these tags and do the access control for the designated per-suite git
> branch in the right way: specifically, in an identical way to the
> existing Debian archive.)
>
> In this scenario most of dgit would no longer be needed, because
> dgit's primary function is to gateway bidirectionally between source
> packages and git branches.
>
> `dgit push-source' (which has frantic paddling ill-concealed beneath
> its fairly friendly exterior) would be replaced by a tiny shell script
> in devscripts to do a few checks and then help you make the right tag
> name and push it to the right place. [1]
>
> That place would not be the main salsa master branch of course,
> because for the reasons you give, because we don't intend to abolish
> *binary* packages. So there needs to be an explicit developer action
> to declare a particular set of source code as the one to build binary
> packages from, for testing and distribution to Debian's users. That
> explicit developer action would consist principally of making a
> suitable PGP signature, as now - except the signature would be on a
> git tag, rather than a .dsc and .changes.
>
I think that it would be great to avoid a schema where we have two git
repositories: the one on the ftp-master side (~ the dgit one), and the
one on salsa managed by the team. And where the developer has to
explicitely git push to both locations, and where both locations are
somehow exposed to users.
Couldn't we imagine a schema where a push of an annotated signed tag to
the salsa repository triggers a gitlab-ci job that notifies a service on
ftp-master that there's a git repo with a suitable signed tag waiting?
that service could then fetch the git repository in question and create
the source package from the tag.
Lucas
Reply to: