[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using a patch naming convention



On Thu, Jan 29, 2009 at 08:41:08AM +0200, Damyan Ivanov wrote:
> -=| Rene Mayorga, Wed, Jan 28, 2009 at 11:05:18PM -0600 |=-
> > 
> >  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.

Agree.

The notation is just to get track if the patch was already sent.
Having a thought, maybe we add a patch and upload the package and wait
a few days before send it to upstream, or if the people who
prepare/uploads the package does not send it for any reason, some else
can do it

> > 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.

We can change number by `prefix' using char, I don't have a strong
opinion on the name/prefix here.

> 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.

I use 'RT: #NNNN` instead of `Upstream-Bug'

> 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?

Yes, and at some point have a review for all patches and if they where
send it to upstream or not.

Having a thought on the Description, the main concern here is that 
not all patches has one at this moment,( the naming schema is 
worst since none packages has it now :p) ) , IMHO using a
naming scheme could be easy to remember and track then a `description
tag' 

Cheers.
-- 
Rene Mauricio Mayorga   |  jabber: rmayorga@jabber.org
http://rmayorga.org     |  
--------------------------------------------------
08B6 58AB A691 DD56 C30B  8D37 8040 19FA A209 C305

Attachment: signature.asc
Description: Digital signature


Reply to: