Re: The Difference between debcheckout and dgit and what they try to accomplish

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Sam Hartman writes ("Re: The Difference between debcheckout and dgit and what they try to accomplish"):
> But my reading of the discussion so far is that people see getting
> patches actually integrated as a pain point.
...
> In the debian-vote discussion people were talking about a eutopia where
> every DD could push to every package.  And if not push, then submit a
> merge request.

Ah, I think I see better now what you are getting at.

If I may repeat back to you what I am hearing.  I proposed the
following solution-neutral problem statement:

 * There is far too much friction and makework caused by Debian's
   antiquated source code management practices.

You feel that this is a big topic, too big to handle all at once, so
you want to narrow your focus.  You wish to prioritise the following
aspect of the above:

 * ... Specifically, there is too much friction involved, after an
   contributor has prepared source code changes to a package, in
   getting those changes actually incorporated in the binary packages
   published by Debian.  (Reducing "friction" does not mean reducing
   review.)

I agree that this is important.  I also think it is possible to
address this *without* compromising the other goals.  Indeed, if we
get this right, it can (at least to an extent) *help* achieve those
other goals.

I do note that my proposed SNPS above does *not* imply that the
contributor is trying to use the maintainer's git workflow.  I think a
key question you are trying to answer with your message is whether we
should try to develop a solution which involves the contributor using
the maintainer's git branch and workflow, or one which involves the
contributor using a dgit view branch.

Am I right about that ?  If so I have an answer but I'm not sure you
will like it...

> If I'm understanding our private conversations, this is not your focus.

I'm not sure "Ian's focus" is the way I look at it.  I have an
ideology of prioritising helping users and downstreams realise their
so-far-often-theoretical software freedom, over improving Debian's
internal processes.

This is because pain from Debian's internal processes is felt by
Debian maintainers who are in a position to change things and highly
motivated to do so.  Whereas the pain felt by users and downstreams is
sometimes neglected.  Users and downstreams need champions within
Debian.

This seems to me to follow fairly objectively from the project's
common ideology as expressed in our foundation documents, combined
with some obvious observations about people scratching their own
itches.

That doesn't mean I don't think we can also help our users and
downstreams (by providing better software), and have more fun
ourselves, by improving our processes within Debian.  And I am very
happy to help with that.

>  But I think that some of your arguments in your response about
> whether something was or was not an advantage made it harder rathre
> than easier for me to see whether I understood the space.

I'm sorry that you evidently found my responses not very helpful.

>     > Unfortunately I don't think it is possible to have the
>     > conversation about how to reduce within-Debian friction without
>     > at least considering how the proposals support or impede the
>     > goal of providing users the source for the code on their
>     > computers.
> 
> We are agreed.
> If we do start with discussing in-Debian friction, it is important that
> the impact of that discussion on other things needs to be inscope.
> If we're solving one problem at a time, we need to include discussion of
> future related work as it impacts our current discussion.

In that case, I have no problem with the approach you are taking.

While I am trying to do more (and think more is achievable), I can try
to confine my comments to the narrower scope.

>     > That's not going to be possible because some possible answers
>     > to what you call "the salsa discussion" make it harder to solve
>     > our users' problems.
> 
> And I think arguments like that need to be in scope.

Great.

I'll wait to see what you say to this "scoping" mail.  Hopefully I can
then go back and read your initial mail again and try to discuss
technical details in a more useful way.

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.