[PATCH 05/10] add patch series function

[文平波]

> 在 2016年8月30日，07:21，Stephen Finucane <stephenfinucane at hotmail.com> 写道：
> 
> On 23 Aug 17:03, WEN Pingbo wrote:
>> Added a ForeignKey in submission, and linked releated patches by
>> 'In-Reply-To' or the first 'References'.
>> 
>> Child emails must fill 'In-Reply-To' or 'References' with correct msg-id,
>> or the parent field will keep empty.
>> 
>> Signed-off-by: WEN Pingbo <wengpingbo at gmail.com>
> 
> I need to think on this a little more, but I don't think will scale
> very well. The main issues is that it's essentially a linked list,
> which SQL doesn't handle well, and the Django ORM handles it even
> worse. Some conditions that I think this would fail on:
> 
> * The cover letter gets dropped by your mailing list (Mailman?)
>    This will mean you've nothing to set as 'parent' for the series
> * You're using nested patches (each patch is a reply to the previous
>  patch) and one of those gets lost
>    Same as above

Yes, if one of patch in series get lost, or email client fills the 
references with empty or wrong msg-id, or a child patch is arrived first 
than parent, the list will be broken.

I think the first of two is not patchwork problem, at least can’t fix in 
patchwork. And I don’t have much idea to find a parent patch precisely 
without correct msg-id so far.

I had try to fix the last case, by walking through all orphan patch if we 
find a submission with empty parent. But it’s too expensive, and I don’t see 
much list recovering in my server.

> * You're using nested patches and your series is rather large
>    This will require N queries, where N is the number of patches in
>    the series

Indeed, we need to spend O(N) time if we get a N depth list. Maybe we can 
add a limit here. Only show the first ten patches in a series by default, 
and user need to click ’Show more patches’ link to load the next ten 
patches in a series.

> The last of these is probably the most serious.
> 
> Have you seen the series work already submitted to the mailing list
> [1]? It still needs work, but it's being actively tested and could fit
> your purposes once merged.
> 
> [1] https://lists.ozlabs.org/pipermail/patchwork/2016-June/002873.html

Thanks, I will check those patches later:)

Pingbo