Raphael Hertzog wrote: > Hello, > > please find below a first draft of DEP-3 that I called Patch Tagging > Guidelines. The idea is to standardize a set of meta-information to embed > in patches that we apply. Please review, share your comments and ideas of > enhancements.
If the idea is to standarize metainformation, I would suggest standarizing filenaming scheme too. What I do in some packages is to name the patches as follows: 0xxx-name.patch -> Grabbed from upstream VCS 1xxx-name.patch -> Interesting for submission upstream 2xxx-name.patch -> Debian-specific The Status field is then no longer needed, since patches in 1xxx should be moved into 0xxx when accepted upstream, or into 2xxx if rejected for non- cosmetic reasons (ie, the purpose of the patch is not accepted, not just the current form). This has the added benefit that patches submitted upstream have a greater chance of applying cleanly against the current HEAD of development. The Origin field becomes optional too. <snip> > > * `Status` (optional) > > This field is a textual explanation of its status concerning its > inclusion in the upstream project. The first line should consist of a > single keyword among "<vendor>-specific" (the patch must not be > forwarded as it is specific to a vendor, ex: branding patches), > "must-be-forwarded" (nobody has taken the time to forward the patch > yet), "forwarded" (the patch has been forwarded, the Bug or Patch > fields should contain the corresponding URLs) or "rejected" (the patch > has been submitted but it has been rejected upstream). Supplementary > lines can be used to explain in more details the status of the patch. > It should be used for example to explain why the patch has been > rejected, or why this change is only meaningful for the vendor. This field misses a value for patches picked from upstream VCS. <snip> > Interpretation > -------------- > > In the analysis of the meta-information, a certain number of related > facts can be deduced from the absence, presence, or combinations of fields > and their values. > > * Has the patch been forwarded upstream? > > If there is a `Status` field, its value answers the question. > If there's an `Origin` field and it contains "upstream" or "backport", > the patch comes from upstream and it doesn't need to be forwarded. > The same is true if there's a `Commit` field. > In other cases, if there is a `Bug` field, then the patch has most > likely been referenced in the bug and upstream should know about it. > Any package maintainer should ensure that the existence of the patch > has been documented in the upstream bug log when he adds the > patches' meta-information. I think answering a simple question (and one of the most likely to be asked about a patch) should be done by a simple rule. The Status field should be sufficient for this. Introduce a picked-from-upstream value for the Status field and then we are done. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org