Re: New Markets

[Max Hyre <mhyre@dasw.com>]

-----BEGIN PGP SIGNED MESSAGE-----

   Dear Debianist(a)s:

   Rushing in where net.gods fear to tread, may I suggest that we
adopt a numbering system like that of the kernel releases?  At least
for stable systems....

   1.1 is about to be released.  Barring the end of the universe in
the next few weeks, we'll find a few problems, or upstream maintainers
will release important bug/security fixes that we *really* want all
1.1 users to have, and can't afford to let slide.

   So we put them in, but introduce a ``patchlevel'' digit into the
version number, so the first real 1.1 release will be 1.1.1, and
everyone runs out to press CDs and sell a bunch of them.  When we find
an important oversight, or a number of lesser ones worthy of inclusion
in the aggregate, they get put in place, and the release is now 1.1.2,
etc.  These changes should *really*, *truly* be limited to
bug/security modifications.  If the incredibly-neat 6.9 version of
Turbo-Doom comes out, with added functionality, it goes in the
unstable tree.  At some time later that gets frozen, and, well, you
get the idea.

(If we want to steal even more from the kernel mechanism, we could
bump 1.1 up to 1.2 when it's declared stable next month, and
thereafter have even minor digits signify stability.)

   I suspect this will be very useful for CD builders, and for trying
to debug problems from folks who just want to *use* Debian---install
it and forget it (of whom we want lots and lots):
    ``My termcap gives me a green on magenta console after I run
	Pong!'' 
    ``Yeah, we fixed that in 1.1.4---upgrade and you'll be fine.''

  On the other hand, I don't think it will scale up to handling
numbering the unstable tree---there are just too many changes in a
continuous stream to try to uniquely label everything as we go.  It
might be useful for the unstable stuff during the frozen period
preceding a new stable release, though.

   A corollary to such a system will be maintaining documentation of
what was fixed when, and which packages changed between any given pair
of revs.  Since I opened my big mouth about this one, I volunteer to
do the writing for such---at least it'll let me contribute
*something*.

   One additional item of value might be the ability to sort out fixes
from function upgrades.  If the next upstream version of Turbo-Doom
fixes a security hole, and also adds the time-travel option, the
package maintainer could apply the first to the stable version, and
send the latter on to the unstable (assuming the two are relatively
orthogonal, and the workload is reasonable).

   My apologies if this has been proposed and rejected previously in
some form I didn't recognize at the time.

			    Max Hyre

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMXfxnfJa20+mce5pAQFV0AP+KnuYTuLKR7qaAxrPksrBtPQz30ijPKn4
ChqV/LU8yzt3w8KDgcbM6KadhzHvY52idy1uQ27RoOu6nQiDLCDlPyyvTq7jKofI
hW8YnxJuHhHPWDRevraUb41w/uJu2Fg5b9AVPBzwvam1sQjV6OWBIRruy+WmokJz
HFSiaVgkLto=
=5WVz
-----END PGP SIGNATURE-----