When I outlined disadvantages and advantages I tried to follow what
people who have been participating in the discussion to date described
as advantages and disadvantages. For the things I listed I have high
confidence that the people involved understood the tools they were using
and their own needs to accurately categorize what they valued.
Clearly we'll need to talk about values for the project as a whole. 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.
>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
Ian> Also: if all you are planning to do is prepare and test a
Ian> patch, then usually the easiest workflow is dgit clone followed
Ian> by some git-format-patch. I have submitted many patches this
Ian> way and no-one has seemed to think them inconvenient.
They are certainly no less convenient than patches submitted through the
bts any other way.
It would not make sense to express inconvenience to an individual
submitter who properly follows our established procedure even if that
procedure is frustrating.
However a lot of patches do languish in the bts for non-rc issues. I
think we've been hearing on blogs, in the debian-vote discussion, and in
feedback from people who do make changes across the archive that they
want improvement here.
I acknowledge it is my job to see if I'm reading comments correctly.
[My comments about being able to interact with the maintainer's work
flow being an advantage]
Ian> That depends, I think, on whether you are trying to (a) join a
Ian> maintainer team, or do "maintainer-like" work; or, (b) do
Ian> cross-archive work with small changes to many packages, or
Ian> archive-wide testing, or similar.
Ian> Any case where the change you want to make is simple, but you
Ian> want to make it to many packages, is much easier to achieve
Ian> with a dgit-based NMU workflow.
Ian> RC bugfixing and other kinds of "passer-by" QA work is usually
Ian> easier with dgit too. You only need to understand the bug, and
Ian> the relevant parts of the package, not hold some git workflow
Ian> stuff in your head too.
Apologies for being a bit repetative.
I understand this is your opinion. I am not sure this is generally
accepted. What I think I'm hearing from people is that they want to
actually be able to get closer to being able to change maintainer
sources than is supported by patches into the bts.
Dgit absolutely can be used to prepare a bunch of patches. But unless
the maintainer actually uses dgit, it's not clear that the result is
easier for the maintainer to merge than a well submitted patch via the
bts produced from apt-get source.
(Yes, if you actually did an nmu, dgit clone users will benefit from the
dgit push).
But my reading of the discussion so far is that people see getting
patches actually integrated as a pain point. If I'm understanding our
private conversations, this is not your focus.
This is an area where I think your focus and the project's desires for
improvements are not aligned.
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.
I think clarifying people's desires and understanding how critical being
able to push to a package and/or submit merge requests to it is will be
an important next step.
>> Conclusions ===========
>>
>> I think that for the discussion I'm hoping to start soon, we're
>> focused on development within Debian. That is, we do care about
>> code not yet released to the archive. We do care about getting
>> future changes integrated, possibly even with little action on
>> the part of the maintainer.
Ian> I think these things are important but:
Ian> for the salsa discussion coming out of the DPL campaign
Ian> I think you are narrowing the scope unduly, perhaps because you
Ian> already have an idea what kind of a solution you want, or
Ian> because you want to solve some problems and leave others for
Ian> later.
I want to talk about solving some problems and leaving others for later.
My prioritization is based on what I've read in discussions so far.
Ian> Obviously it's up to you what you want to prioritise but I
Ian> think we need a solution-neutral problem statement.
Ian> For me, that is:
Ian> * There is far too much friction and makework caused by
Ian> Debian's antiquated source code management practices.
I don't think I could run a discussion that broad and get anywhere. If
you or someone else would like to take a crack at running a discussion
that broad, I'm open to stepping back for a month or so and seeing where
the discussion gets. I'd think a month ought to be enough time to see
if things get stuck or if we're making forward progress.
I don't even know that I'll succeed with my current approach, but I
wouldn't know where to start with the problem statement you outline.
Ian> Unfortunately I don't think it is possible to have the
Ian> conversation about how to reduce within-Debian friction without
Ian> at least considering how the proposals support or impede the
Ian> goal of providing users the source for the code on their
Ian> 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.
>> What I do know is that I think I'm already worried about whether
>> the discussion is too big. I'm going to try and focus on what I
>> said I'd focus on because that's valuable. There are other
>> things that are also valuable; by trying to narrow my own
>> thinking in this instance I'm trying not to make a judgment about
>> them.
Ian> That's not going to be possible because some possible answers
Ian> to what you call "the salsa discussion" make it harder to solve
Ian> our users' problems.
And I think arguments like that need to be in scope.
