-=| Rene Mayorga, Wed, Jan 28, 2009 at 11:05:18PM -0600 |=- > > Working on some other teams I notice a nice and interesting naming > convention to patch names[0] > > The idea is to stand a status of the patch using a name convention, with > status I mean: > 1) Patch is Debian specific and there is no need to send it to upstream I agree that this would be grasp by looking at the patch name > 2) Patch needs to be send to upstream > 3) Patch is already sent, and needs to be removed on the next release if is > included. I think the policy here should be that patches not specific to Debian must be sent upstream. So if the 1. rule is used, anything that does not fall there is sent upstream, no need for special notion. > This is my personal approach, based on[0] > > Each point on this can have then a prefix on the name that tell to everyone the > state of the patch > like 00X_foo_bar.patch for option 1, > 10X_bleh.patch for option 2 > and 20X_baz.patch for option 3 Numbers suggest ordering, which may not be the case. debian_ or deb_ or fix_paths_on_debian (or other name that makes it obvious this is Debian-specific) is what I'd use. > By using this we can have a nice way to know the status of the > patches without looking at RT/BTS, this will help to reduce on line > from our TODO(OpenTasks)[1] The patch description helps here. I think we have some sort of standard headers established lately: # Author: Name <email> # Description: what the patch does and why # Debian-Bug: http://bugs.debian.org (after writing these the patch is ready to be sent upstream) # Upstream-Bug: http://upstream.bug/url (after sending) Of course, having Debian-only "flag" encoded in the name makes it more visible, so it would be nice. Hmm. Is the idea to track all the patches that are not sent upstream, but should be? Perhaps "Upstream-Bug: not to be reported" or some such can help grepping? -- dam JabberID: dam@jabber.minus273.org
Attachment:
signature.asc
Description: Digital signature