[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Discussion on eventual transition away from source packages



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: