Silly question: debian/patches prefix-numbers

[Loïc Minier]

On Wed, Oct 17, 2007, Fabian Greffrath wrote:
> I am wondering if there is a convention for the use of numbers in the 
> patch name prefixes (in Debian or maybe even in the OSS world) that I 
> haven't heard of. Is there any reason why we use 60_ and 70_ for these 
> patches and other prefix-numbers for other patches other than 'keep them 
> in the right order somehow'?

 There's no convention that I know of, but I tried explaining the rules
 I follow in the teams I work with and to my sponsorees: I basically
 number quite low "long term" patches which are either very Debian
 specific, wont ever make it upstream, or in general will stay for long.
 I number quite high patches coming from upstream or very likely to be
 accepted upstream.  I number relatively high the autotools' generated
 files patches.

 I tend to look for number 70 for the autotools generated files patch
 (the one where I /only/ run autotools, not touching real source files,
 so the one resulting of things libtoolize, aclocal, autoconf, automake,
 autoheader, such stuff).
   I tend to use numbers 9x for patches coming for patches from upstream
 SVN, CVS, next tarball or which upstream agreed to commit but /only/ if
 these patches don't touch autotools files (configure.in/ac Makefile.am
 etc.), otherwise they naturally need to be in the 6x, before 70.
   I tend to use 6x when I'm quite confident that the patch will make it
 upstream (trivial changes) or rather will disappear with next upstream.
   I decrease the patch number when I'm less confident.

 Hope that makes some sense to you; the idea is to try to keep the
 "most stable" parts of the patch stack at the bottom of the stack so
 that only "volatile" / recent patches need to be rebased.  It means
 it's also less likely that I need to rebase the patches that we keep
 across upstream releases or patches depending upon these.

   Bye,
-- 
Loïc Minier