Le lundi 15 juin 2009 à 18:12 +0200, Raphael Hertzog a écrit : > * `Patch` (optional) > > URL pointing to the patch. It can be in a VCS web interface, > a BTS attachment, etc. If the patch is available in the upstream VCS > or BTS, those URLs take precedence. Maintaining this information up-to-date can be troublesome. > * `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. Same here. At the moment a package is uploaded, it can be must-be-forwarded, then later it becomes forwarded and later on it can change again. Which means a lot of additional commits, and that the version in sid can be easily outdated. It’s not that we can’t live with these issues, but we need to be aware of that. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=