Thomas Klausner <wiz%NetBSD.org@localhost> writes: > When sending patches upstream, it's often helpful to know why a patch > was added to pkgsrc. For this, we have the possibility to add a > comment in the patch files below the RCS Id and above the start of the > patch itself (or browse the CVS history, but I want to avoid this in > future...). > > I see the following cases of patches: > 1. Patches are only needed for pkgsrc and don't need to be sent > upstream (e.g. to install config files into share/examples instead > of the location used by the program) > 2. Patches that should be sent upstream > 3. Patches that were sent upstream in the current version > 4. Patches that were sent upstream in a previous version > 5. Unidentified patches > 6. Mixes of the above > > I'd like to have some special strings to mark these up; for now only > for the simple cases (i.e. 1-5). Probably some yelling will do > the trick, i.e. a separate line in the comment section, consisting of: > 1. PKGSRC > 2. (comment, but no marker) > 3. UPSTREAM YYYY/MM/DD URL or > UPSTREAM YYYY/MM/DD author%example.com@localhost > 4. same as 3? Difference can be seen by comparing the date to the RCS > Id date (will probably not be completely correct in all cases, but > fine for a start) > 5. (no comment) > > Ideas how to handle 6? Perhaps enumerate the chunks and add comments > per chunk... but I don't want discussions about this to stop the > implementation of the rest. That's basically fine, but I think formalism/machine-readability is not that important. What's import is that someone who does cat patch-aa should immediately and clearly understand if the patch should be sent upstream and if it has (and when). If it has, a URL to a bugtracker entry or an archived mailing list post should be given. For config files, often upstream can be patched to spiff up configure, and then we can just use it. I've done that for quagga long ago. So "we need to munge for pkgsrc" and "upstream does not need changes" are not quite the same. But it's different from "upstream has a bug and they'll definitely want this".
Attachment:
pgpC2eXXCeg18.pgp
Description: PGP signature