Re: Discussion on eventual transition away from source packages
Hi,
Could you stop playing with Reply-To and leave those prospective
discussions where they started? I think that it's perfectly expected for
discussions around questions asked on -vote@ to diverge a bit into
interesting sub-threads. That's just how DPL campaigns work.
It's the second time today.
Lucas
On 21/03/19 at 18:29 +0100, Andreas Tille wrote:
> Hi,
>
> +1 for the suggestion of Lucas
>
> -1 for discussing this on debian-vote making it hard to find later
>
> Reply-To set to debian-devel.
>
> Kind regards
>
> Andreas.
>
> On Thu, Mar 21, 2019 at 06:21:15PM +0100, Lucas Nussbaum wrote:
> > 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
> >
>
> --
> http://fam-tille.de
>
>
Reply to: