Annotating superseded/accepted patches

[Carl-Daniel Hailfinger]

Hi Jeremy,

On 30.09.2009 09:43, Jeremy Kerr wrote:
>> is there some way to store by which patch an existing patch was
>> superseded, preferably with a link to the newer instance? The web
>> interface only lets me change the state to "Superseded", but there is no
>> text field (or dropdown box) where I could enter a patch number or patch
>> name.
>>     
>
> The grand-plan for this is a 'patch relations' table, containing (patch_from, 
> relation, patch_to) tuples. This way, we can store all sorts of stuff:
>
>  * patches that are in the same series
>  * patches that supersede other patches
>  * patches that are follow-ups to other patches
>
> This is a bit of a longer-term project, as it'll require a bit of work to get 
> right, mostly on the parsing-side of things (ie, figuring out when a patch is 
> in a series is non-trivial).
>   

Designing the relation model on top of (patch_from, relation, patch_to)
will be non-trivial, but the parsing will be a tough nut to crack,
considering that sometimes followup patches in a thread do not obsolete
the original patch, but rather fix a related bug. May I suggest some
patch similarity metric (e.g. have the web interface print "The
following patches were posted as followup to this patch, with xy%
similarity to this patch").


>> By the way, is there any official policy for or against making the
>> commit ID clickable?
>>     
>
> No policy, I'd suggest something like a 'rcs_url' in the Project object, which 
> we do a template replacement on, containing something like:
>
>  "http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=%s".
>
> If you forsee having to use other parameters in the template replacement, we 
> could use the python dict-style template parameters:
>
>  "http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=%(commit_id)s".
>
> but the downside here is that the database contents will become python-
> centric.
>   

AFAICS the first example would be totally sufficient for coreboot and
flashrom. Not sure how to handle a patch which ended up being split into
multiple commits (forgotten file add...), though.


> If you're keen to do this, go ahead. Otherwise, I'll add to TODO.
>   

My Python skills are very basic, but I think I can hack up a patch.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/