Re: RFC: using supersedes: trailer to indicate patch/series revision flow

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Geert,

On Fri, Nov 08, 2019 at 10:59:55AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 8, 2019 at 9:31 AM Han-Wen Nienhuys <hanwen@google.com> wrote:
> > On Fri, Nov 8, 2019 at 12:45 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > 2. Should supersedes: link to the previous version of the patch, or the
> > > >     first ever version of the patch? I am leaning towards the latter,
> > >
> > > And then how do you know that version 2 was superseded by version 3?
> >
> > You throw the message ID into a search engine, and see what it returns.
> >
> > The advantage of keeping the patch series ID stable is that you can
> > consider a patchseries as a document and then easily index it inside a
> > service (say, patchwork) using Lucene, ElasticSearch or some other
> > common technology.
> >
> > If you make the "supersedes" refer to specific versions, a workflow
> > service will be more susceptible to errors if messages were lost, and
> > the service has to work harder to aggregate the different versions of
> > a patchseries together.
> >
> > Is it common for different authors to superseed each other's patch
> > series? If yes, "superseeds: precise version" is more precise, if not,
> > you get the same information from the timestamp of the cover letter.
> 
> All/most of the above applies only to versioning of patch series that
> implement a fixed feature, with a fixed scope.
> So Vn+1 is really an improved version of Vn, and nothing more or less.
> 
> But this does not apply to many patch series in Linux kernel development.
> Patch series may
>   - grow (more patches added),

This shouldn't be a problem, as the new patches get posted for the first
time, and thus don't supersede anything else than what the previous
version of the series contained.

>   - shrink (some patches rejected, or already applied independently),

This should also not be an issue, as the patches that are dropped or
that are already applied will not be resubmitted separately.

>   - be split in multiple series,
>   - dropped but some parts reused in other series (possibly by someone
>     else),
>   - ...

These are the difficult cases :-(

> That's the hard work in patch tracking.
> 
> So series IDs do not cope well with this, and "superseded" really should
> apply to individual patches, not series, too.

-- 
Regards,

Laurent Pinchart