Re: why this marketing stuff is important

[Craig Sanders <cas@taz.net.au>]

On Sat, 16 Aug 1997, Dale Scheetz wrote:

> On Fri, 15 Aug 1997, Craig Sanders wrote:
> 
> > i'd like to see them in bookshops too - but not at the price of
> > completely destroying debian's dynamic update nature (which is, imo, one
> > of debian's best features)
> 
> We can do both. For the retailer it is a matter of not changing the
> release numbers. The way we deal with prompt fixes and updates has little
> to do with what order they go into the stable distribution, so why assign
> any numbers to those changes (outside the version numbering of the
> packages themselves)? It isn't necessary.

i agree. i see very little point in a version number for debian itself.
it's the package versions which are important.



> We can support both.
>
> When hamm passes through "frozen" and becomes "stable", if it is
> called 2.0 then a link to hamm from 2.0 gets created, along with
> hamm-updates and hamm-testing. Packages that their maintainer
> thinks will fix problems in hamm are directed for installation in
> hamm-testing. When they have been "adequately" tested, they become
> candidates for hamm-updates. The directory, hamm-updates, should
> contain a ChangeLog that contains the changes registered against
> each of the packages found in hamm-updates, so that users can easily
> identify which packages they need from updates and which they can
> leave alone, without having to download the whole pile of packages.

expecting the users to do all that manually is too much. that sort of
thing is what computers are for....and dselect can already do it.

a new tree (stable-updates) populated by packages and symlinks into
stable for dselect to use does this much better...especially when you
have several machines to administer/update/keep secure.  One of the
reasons I use debian is that i don't have to download numerous update
files to several dozen machines - i just point dselect at my mirror,
choose the latest stable or unstable tree, and then run Update, Select,
Install etc.

I don't care what the directory is called, or whether it has a new minor
or minor.minor number on it as long as the directory is there for users
to point dselect at.

i think that just calling it stable-updates or stable-fixed (with no
revision number or date) would be an acceptable compromise.  Crippling
debian's dynamic update nature (by deliberately choosing not to make a
dselect-able tree) is not acceptable.

we did something similar to this for rex, but with minor version
numbers. if the minor versions are causing problems for cd makers then
get rid of the numbers, not the dselect tree.

(i've always thought that the only reason we have a version number for
debian-as-a-whole is for CD-rom makers anyway - in debian, the only
version numbers that really matter are the versions of the individual
packages)


> Does this satisfy your needs for timely fixes? I know that for some,
> unstable is their first recourse to problems with the stable release,
> while others want those fixes to propogate into stable. 

i use unstable on my workstations, and stable on my "production" server
machines...when unstable gets stable enough, the servers get unstable
too.

i think that only the most important security and bug fixes should propagate
from unstable to stable.


> (Some of these just can't be moved "down" into stable, because of
> dependencies on unstable packages that will never move into stable
> {like libc6})

yes, that's true. at some point in the next few months, it wont be
feasible to make updated packages for libc5/stable - too many packages
will have changed, and too much will depend on packages only available
in unstable.

craig


--
craig sanders
networking consultant                  Available for casual or contract
temporary autonomous zone              system administration tasks.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .