On Mon, 15 Jun 2015, Vincent JARDIN wrote:
$ git send-email -1 --subject-prefix 'PATCH v2' --annotate --to
[email protected] --cc <everybody discussing the patch>
--in-reply-to <Message-ID of the previous patch>
So my problem with all of this is that patchwork isn't quite clever enough
to figure out what emails with patches supercede which others. I think the
above results in a new thread and hence a new patchwork line anyway.
So I can't really rely on patchwork to tell me the status of a patch, I
need to use my MUA to search the list (least, for me alpine has much
richer ways to search than patchwork, and alpine allows you to iteratively
apply constraints to the search results).
Indeed, I'll go as far as to say that using an email list to track patches
just inherently sucks, because there are so many different ways you can
construct emails. It need not be obvious one email references or
supercedes an earlier one. Ditto, people sometimes reply to old emails but
intend to start a new thread, etc.
I like email lists for communicating with others, discussing changes, etc.
I don't like email lists for tracking patches. And it seems the inherent
limitations will intrinsically carry over to software that tries to follow
email lists to track patch state - least, patchwork just doesn't do it for
me.
I'd much rather use git to track submissions.
I'd much rather that regular contributors had a git repo with an obvious
"this is what I've proposed to merge" head (volatile/merge or whatever).
It's easy to setup remotes and regularly fetch them. It's easy for the
contributor to update the head and ensure others see the most recent
version.
So the workflow (for regulars at least) becomes:
- prepare a 'volatile/merge' branch with commits
- send new commits to the list.
Then every X time (week or two) someone prepares a 'summary' of what is
outstanding, with pointers to patchwork or git-webby things, and we go
through it (as Vincent did quite successfully the last few weeks).
If needs be, we can setup git hosting for anyone who wants it. We used to
allow 'people' git repos for quite a while. Maybe we can bring that back
(gitolite ?).
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Carswell's Corollary:
Whenever man comes up with a better mousetrap,
nature invariably comes up with a better mouse.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev