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

Re: tag2upload (git-debpush) service architecture - draft



On Thu, 2019-08-01 at 04:37:41 -0700, Sean Whitton wrote:
> On Wed 31 Jul 2019 at 10:53PM +01, Rebecca N. Palmer wrote:
> > Do "complicated and inconvenient" mean "harder to remember than 'git
> > debpush'" (which could equally well be fixed by a local-only script),
> > the confusing errors mentioned below, or something else?
> 
> It's a qualitative claim about what it is like to use the tools.  We
> think that use of git-debpush imposes much less Debian-specific
> cognitive load on package maintainers.  They are just signing and
> pushing a git tag.

But Debian-specific work requires Debian-specific knowledge.

> > On 31/07/2019 20:21, Sean Whitton wrote:
> > > Just fyi, it is indeed as simple as [dgit push-source && git push --all --follow-tags].  However, when
> > > there are errors, it is quite a bit harder to understand what's going on
> > > than it is with git-debpush/tag2upload, basically because there are
> > > .dscs involved.
> >
> > If git debpush / tag2upload have better error handling, could that code
> > be used to improve dgit push-source?
> 
> The sense in which git-debpush & tag2upload have better error handling
> is just that the user's computer is not responsible for any .dsc
> manipulation.  This makes it easier to have the correct mental model of
> what's going on, and thus what went wrong.
> 
> As soon as .dsc generation is happening on the user's machine, you
> introduce a whole load of stuff which the user has to incorporate into
> their mental model of what's going on with the command they just typed.
> 
> You and I basically already have all that stuff in our heads because
> we've been doing Debian stuff for a while.  We want experienced
> contributors to be able to discard it, and new contributors not have to
> learn it.

This argument seems very counter-intuitive. This assumes a
Debian-archive-centric world-view, where most of the heavy lifting is
delegated to some external service. But the reality is that most
maintainers, and other external parties handling Debian sources do
need to handle actual source packages. Requiring people to setup an
equivalent to the Debian archive + dgit service + tag2upload "locally"
just so that they can reduce their cognitive load, seems to be pretty
much the opposite to the above stated goal TBH.

Personally I'm more interested in simplifying our toolchain and
concepts so that this cognitive load is reduced for everyone/everything.

Thanks,
Guillem


Reply to: