On Sun, 18 May 2008 19:40:34 +0900, Charles Plessy wrote: > Le Sun, May 18, 2008 at 12:27:10PM +0200, David Paleino a écrit : > > > > Can we standardize the patch header? Be it quilt, dpatch, $foo, the header > > might be something like: > > > > Author: > > Forwarded: > > Description: > > > > I'm currently starting to use this format: > > > > Author: Foo Bar <foo@bar.com> > > Forwarded: no | http://$url_of_upstream_BTS_with_patch > > Reason: foo > > another line > > . > > Another paragraph > > Hi David, > > I think that the Reason: field is not necessary, as one could use: > Forwarded: no, because blablablah… Sorry if that was not clear. "Reason" might be "Description": why is the patch needed :) (not reason of rejection/not forwarding ;) > I just read one of the messages of Pierre Habouzit, in which he says > that for the glibc packages the forward status is also encoded in the > patch name. It can be a good idea as well, although it would generate > bigger diffs on our commit list. Yes, I've read that too. > I also like the idea that a bug is fixed by a patch, but would be closed > only by a new upstream release that makes the patch unnecessary. In our > case, we could for instance retitle the bug and downgrade its severity > to wishlist when we apply a patch. But I wonder if it would blur the > information in the changelog. I meant upstream's BTS. Please take a look at: http://code.google.com/p/galaxium/issues/list?q=reporter%3Ad.paleino&can=2 It's a package I'm preparing -- I report issues, attach a patch, and use: Forwarded: http://code.google.com/.../?id=xxx :) (this is IMHO much clearer than using our BTS and forcing upstream follow us...) > Let's experiment with real work and turn it into a Debian-Med policy > before discussing it on -devel. Yes. I'm sorry I'm not very active in Debian-Med at the moment, but I'm concentrating on creating a Dentist Management software :) -- besides University studies. > We are not far from the freeze (do not forget that 9 days before the freeze > it will be already too late for urgency=low tasks!), and we have many uploads > to do; each of them is a good opportunity to build a Policy by practice. I see this as a long-term goal, surely not-for-lenny. > Ah, I just realised that I forgot to answer to your question. > Standardising the fields and their order is definitely a good idea :) Great :) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature