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

Re: [RFC] Proposal for new source format



gregor herrmann writes ("Re: [RFC] Proposal for new source format"):
> On Thu, 31 Oct 2019 11:59:07 +0000, Ian Jackson wrote:
> >  * tag2upload service, or some related service:
> >     - determines that the maintainer is using a dgit-compatible git
> >       workflow, by looking at the tags, and looks at some in-dsc
> >       metadata to find the maintainer's repo
> >     - determines that the maintainer is using salsa or launchpad,
> >       converts the NMU to the maintainer branch's format, and
> >       submits an MR
> 
> … after checking that the current state of the git repo corresponds
> to the current version in the archive (which is often not the case in
> my experience with NMUs) …

Right.  This is one of the difficulties with the ad-hoc maintainer
branches you find on salsa.  And it is one of the ways that dgit
helps.

An NMU done with `dgit push-source', and starting from `dgit clone',
always gets this right.  But if the maintainer didn't use dgit to
upload, `dgit clone' produces useless history, so the NMUer has to
cope with lack of history; or if the NMUer wants history they can dig
around in salsa.  But if the NMUer fetches a branch from salsa it is
not so easy to make sure that they start from the right git commit
(and not possible to make a tool which gets it right every time).

My enhanced scheme as I propose above could also get all this right.
The NMUer would use `dgit clone' and they would see proper history
because the maintainer had used tag2upload.  So the NMUer's
canonical-view git branch starts at the last upload, as it should.

The tags specify where all the relevant versions are.  So the
converter can make a maintainer view branch starting at the
maintainer's last upload.  That's what would become the maintainer
view MR.  (It could be rebased if desired.)

Ian.


Reply to: