hi, (yay for group reply) On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: > * `Description` (required) > > This obligatory field contains at least a short description on the > first line. Supplementary lines can be used to provide a longer > explanation of the patch. given that the patches which currently have useful information do so via freeform comments, i think that it would be very useful to explicitly include this in the format. i.e. anything that doesn't conform to the standard header/value format could be taken as the description. > * `Origin` (required) > > This field should document the origin of the patch. It can have the this guy feels a bit over-engineered/over-generalized to me. > * `Bug-<Vendor>` or `Bug` (optional) > > It contains one or more URLs (space separated) pointing to the related bugs > (possibly fixed by the patch). The `Bug` field is reserved > for the bug URL(s) in the upstream bug tracker. if Bug can refer to more than one bug than perhaps "Bugs" would be better, or alternatively you could allow the field to have duplicate instances. Also, from reading this i'm assuming that debian bugs would be identified by "Bug(s)-Debian"? that seems a bit unwieldly, esp given that there will likely be more references to debian bugs than upstream/cross-stream bugs. Maybe we should also add a special shorthand for "Closes: #nnn" or similar? My personal preference is that Debian gets "Bug" and there's a seperate "Bug(s)-Upstream" field, but maybe there are also arguments to the contrary? also, for the more commonly referenced BTS's (BTS and LP) it'd be nice for the spec to allow us to refer to them in shorthand (#nnnn or LP#nnnn). > * `Status` (optional) honestly i don't see this as something that people would keep up to date. i think that it's something that could rather be implicitly determined with smart use of existing information (assuming that there are debian and upstream bugs to reference, and possibly some bts-link glue). and since it's by nature rather volatile, i think it otherwise invites extra and un-needed work for the maintainer. > * Has the patch been forwarded upstream? why not have a field for that instead? for example: * `Forwarded` (optional) Has the bug been forwarded to upstream? Any value other than "No" or "no" will be taken as a postive value. If the value is a URL, then it is inferred that it points to an online discussion related to forwarding the patch to upstream. The value is also implicitly considered positive if there are upstream bug references elsewhere in the headers. this would allow for: Forwarded: Yes -or- Forwarded: http://lists.upstream.org/msg12345.html -or- Bug: http://bugs.upstream.org/bug12345.html (which implicitly states that it's forwarded) i guess there's still the corner case where we found an upstream bug and fixed it locally but did not send the patch back but referenced the upstream bug in the patch anyway, but that's just... mean (and bts-link or a simple human observation would show that the bug hadn't been forwarded). On Mon, Jun 15, 2009 at 06:27:45PM +0200, Lucas Nussbaum wrote: > > (possibly fixed by the patch). The `Bug` field is reserved > > for the bug URL(s) in the upstream bug tracker. > > What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to > indicate which Debian bug is fixed by this patch? Debian: could be considered a shorthand alias for Bug-Debian maybe? I guess that could also address the above issue that i mentioned. > I Think that there's one field missing: DebianSpecific. This field would > indicate why the patch is Debian-specific, and should not be forwarded > upstream. i think something like this would be useful as well. i'll throw a suggestion out there: * `Debian-Specific` (optional) Is this patch a debian-specific patch that is not intended to be shared with upstream? For example, changes to specify Debian-specific application paths, configuration file locations, etc. On Mon, Jun 15, 2009 at 07:04:59PM +0200, Josselin Mouette wrote: > > * `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. i don't think it's incredibly interesting either, apart from "where did this come from", which kinda blurs together with "Origin" at least in my mind. I think if Origin were made a little less general it could also assume the purpose of this field. On Mon, Jun 15, 2009 at 09:37:43PM +0200, Joerg Jaspert wrote: > It does sound a *little* overengineered for no good reason. (IMO). yeah, i also think it could be simpler without failing the original intention. also, the use of "optional" vs. "required" seems a bit presumptuous given that there's nothing requiring anything at all in the patch headers atm. > How about starting to do that for your own packages and see how it works > out. If it turns out to be great people will join and it will spread and > at some point be something we could even enforce. Would also give this a > little practice test to see if what you want from people is worth the > work/trouble dealing with it. jftr i have no problem implementing whatever comes from this into the patch tracking system, which should hopefully make the efforts more visible (and maybe even more useful). sean
Attachment:
signature.asc
Description: Digital signature