Have parse_and_add_attachments process all attachments; revise ispatch logic. #63
Description
Activity
My goal here is to get CFBot out of the business of scraping the mailing list archives for attachments and instead have Commitfest serve them up via the new CF-API.
+1, that's a target we should be aiming for.
That requires the Commitfest add all of the attachments served up by the ML-API, not just the first one. Since the ML-API provides the information is there a reason to not do this?
Not a reason I know at least. The only thing to be careful of in my opinion is that we should make sure that if you have a large patchset, with many versions that it doesn't clutter the page too much.
On a related note, the check_patches_in_archives.py heuristic for detecting whether a file is a patch file seems to differ from CFBot. Any reason not to likewise synchronize their beliefs on this point?
Seems good to synchronize them.
The only thing to be careful of in my opinion is that we should make sure that if you have a large patchset, with many versions that it doesn't clutter the page too much.
Before deployment I would ensure /patch/# only ever shows the most recent message with patches on it, and the most recent message overall (if different). Per-thread. The CFBot API would also only expose the most recent message with patches on it. (Maybe the most recent period but only if that unified the API in a material way.)
(I do need to explore the annotations feature still, as well as comments and review.)
The main issue would be storage and pruning but that seems quite manageable.
I feel like the case where there is published a v7 and someone wants the v6 patches they can follow the link to the archives and find the message with the v6 patches on them manually. CFBot doesn't do historical. And we already send them to the archive to get the patches today anyway. This would allow for using the CFApp to download the entire set.
If we want to retain some kind of exploratory GUI for "Show all attachments" I would redo it as a two-column page, left side with selectors for messages and the right side to list the attachments for the selected message. With a drop-down at the top to switch between threads. But that seems like a debugging tool that may or may not be desired (but easy enough for someone to try their hand at for learning purposes).
My goal here is to get CFBot out of the business of scraping the mailing list archives for attachments and instead have Commitfest serve them up via the new CF-API. That requires the Commitfest add all of the attachments served up by the ML-API, not just the first one. Since the ML-API provides the information is there a reason to not do this?
On a related note, the check_patches_in_archives.py heuristic for detecting whether a file is a patch file seems to differ from CFBot. Any reason not to likewise synchronize their beliefs on this point?