>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
Ian> Ansgar Burchardt writes ("Re: Preferred git branch structure
Ian> when upstream moves from tarballs to git"):
>> Sam Hartman <hartm...@debian.org> writes: > OK, I didn't hear
>> that as an answer but think I'm coming to the same > conclusion
>> that Ian did after reading your mail. > It sounds like you are
>> talking about having the Debian packaging in a > separate
>> repository from upstream. > Do I correctly understand the model
>> you are talking about?
Ian> ...
>> I'll point to [1] for what complexity this avoids. Try
>> explaining that to someone without advanced Git knowledge...
>>
>> [1]
>>
https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html
Ian> I am getting increasingly unhappy with your tone, and with the
Ian> thrust of your arguments, in this thread. Your messages feel
Ian> very hostile to
I'd like to try and step in.
Ian, it sounds like you're frustrated.
I'd like to understand exactly why.
Is it that you're frustrated because you've spent a lot of time
working on documenting what you think is the simplest, best option, and
others are disagreeing?
I do find the work you've done valuable. But like Ansgar I find that it
demonstrates there is a lot of complexity in the dgit work flows. I
don't think this is a criticism of your work; I think that the reason
people are pointing to your work is that it clearly demonstrates the
complexity.
I also know that it's easy to sweep the complexity that we're familiar
with under the rug. I hear your concern that people advocating other
approaches may be hiding complexity and that we need to be careful not
to hide complexity simply because it is undocumented.
That said, I think Ansgar has some really valid points. I think that
dgit (or git-dpm) are the hardest work flows to teach.
One of my coworkers in a debian developer.
I could teach him dgit (although I think he already knows it
reasonably).
I would not expect to succeed at teaching dgit or debrebase to the other
two engineers at my company, although I'm kind of tempted to try as a
discussion point.
I was going to argue that I thought teaching gbp pq was easier than
dgit, and that's true up until you have to update a patch.
I do think I could teach the other engineers separate debian repository.
That's certainly true assuming that upstream doesn't need to be changed.
I think that so long as I said redo your patches from scratch every new
upstream release I could even teach separate debian repositories.
By teach dgit I mean teach dgit well enough to add an upstream patch,
and migrate that across to upstream releases as they change.
I think that patches applied git workflows have a lot to add. I know I
don't want separate debian repositories as my preferred workflow. But I
do think there really is a lot of complexity here, and I think that it
is a lot easier to get someone started with some of the simpler
workflows.
That said, I also hear your argument that for downstreams who are
want to just add a patch or two (and throw it all away and start over
when they take a new upstream), patches applied workflows are easier.
