Hi Doug,
* It looks like "In-Reply-To" isn't super easy as a method for
collecting groups of patches since git send-email can run in a number
of different modes (chained replies vs not and also the "in-reply-to"
option). It could be used (and would be more robust than my
heuristics), but we need to be careful to test all of the different
modes.
Yes, and I think we can handle all of these, especially as we keep the
message-id of every patch and comment; we could scan the contents of the
In-Reply-To and References header looking for linkages to patches in the
same series.
* In practice, the heuristics that I've used seem to work really well
to identify groups of patches. I have yet to see them fail as long as
all of the patches are actually visible.
I was planning to use some of your logic in the patch parser too :)
One really helpful thing would be some contributions for testcases;
especially when the parser receives patches out-of-order.
What format are you looking for for test cases? I'm happy to dig
through email folders and find some interesting ones.
Ideally, these would be additions to the existing tests in
apps/patchwork/tests. Check out patchparser.py in particular. Of course,
this will depend on which implementation we end up using, so maybe just
collect a few examples of different threading styles for now.
Cheers,
Jeremy
_______________________________________________
Patchwork mailing list
[email protected]
https://lists.ozlabs.org/listinfo/patchwork
