joerg@britannica.bec.de wrote:
> On Wed, Apr 19, 2006 at 10:20:22PM +0200, Georg Schwarz wrote:
>> 
>> * When a new patch is created, it is to be named as to fill existing  
>> gaps in the naming order created by previously removed patches as  
>> long as such gaps exist (at least that's how I think it has been done  
>> so far)
> 
> This is not always a good idea. If you want to have a patch included
> both in HEAD and stable, it makes a lot sense to use the same name.

When I add patches, I actually check the Attic to see if any previously 
used patch-[a-z][a-z] had patched that file in the past, and if so, then 
I resurrect that patch name.

As a pkgsrc developer, my main concern with working with patches is 
being able to track how each source file is being patched across package 
updates without needing to inspect every patch's CVS history.  For this 
reason, I actually think we should go with one big patch file 
per-package that is the concatentation of all of the single-file patches 
we currently have.  The current naming scheme is just an artifact of the 
original FreeBSD ports import, and even FreeBSD ports has dropped the 
patch-[a-z][a-z] convention for quite a while now.  If there was an 
automatic way to name patches based on the filename being patched, that 
would also solve the problem I mentioned, but I notice that the patch 
names tend to get incredibly long and ugly.

To flesh out the "jumbo patch" idea, we would create a make target that 
explodes the jumbo patch for the benefit of developers so they can 
selectively apply individual sub-patches.  We would also create a make 
target that concatenates the patches into one big jumbo patch in a 
consistent way (probably based on sort order of the file being patched), 
which can then be committed to pkgsrc.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>