Re: [RFD] Explicitly documenting patch submission

Linus Torvalds
2004-05-23T17:06:51Z

On Sun, 23 May 2004, Horst von Brand wrote:
>
> > So, to avoid these kinds of issues ten years from now, I'm suggesting that
> > we put in more of a process to explicitly document not only where a patch
> > comes from (which we do actually already document pretty well in the
> > changelogs), but the path it came through.
>
> How will the path be preserved? Does BK do it now? Can it be transferred
> into CVS (for paranoid CVS-won't-screw-us-ever people)?

It will just be in the changelog comments, so yes, BK will preserve it.

The path _inside_ BK is different - BK won't update the changelog
comments, so basically once it hits BK (or any other SCM, for that
matter), it's up to the SCM to save off the path details. BK does this by
recording who committed something, and recording merges, so the
information still exists, but it's no longer in the same format.

> Does this mean that only the repositories contain the certificates,
> "final source" doesn't?

Well, if you use some format that doesn't preserve patch boundaries (like
exporting it to a plain tar-file), then clearly you can't save the patch
submission details either. So yes, if you use just plain CVS to export it,
or do a "bk export -tplain", the information will be gone. I don't see
how you _could_ save the information at that point - you're literally
asking to "flatten" the submission tree.

> Just make sure the relevant open source licenses are in Documentation, and
> so is the Certificate du jour.

Yes, I was planning on adding it to Documentation, and also putting a big
pointer to it into Documentation/SubmittingPatches. But this is obviously
not something I can do unilaterally, so first we'd all need to agree that
it's a good idea to do this process.

BTW - there are later stages that I would like to do, like having
automated "acknowledgement" emails sent out when a patch hits the main
repository. The same way that people now have robots that send out the
full patches to the patch lists when a patch hits the kernel.org
repository, we can use this thing to have people who have signed up for
acknowledgement be notified each time a patch that they signed off on hits
the repository.

Not everybody will necessarily care, but I know some people have asked for
a positive ack on when their patch finally hits the "official" trees, and
this sign-off procedure would put all the infrastructure in place for
automating that kind of service.

Linus