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

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



Hello,

On Thu 01 Aug 2019 at 02:35PM +02, Guillem Jover wrote:

> 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.

I should have said: Debian-specific source code handling knowledge.

I'd like there to be more room in people's minds for Debian-specific
knowledge that isn't a matter of moving source code around.

>> 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.

Hmm, I'm not sure all that local setup would be needed.  You can start
with `dgit clone` and work from there.

More generally, I think we should aim to replace the use of source
packages in all those places too, but there are lots of unsolved
problems there.  I don't think anyone knows what things are going to
look like.

tag2upload is meant to encapsulate the use of source packages in one
place, as a modest first step towards replacing them elsewhere too.

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

We should do this too, of course :)

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: