Re: Debian development modem (was The broken libjpeg-6b is in RH 5.1)
> Now Debian is a community-based project, which is partly what
>attracted me to it (and I suspect I may not be the only one in that
>respect), and indeed I hope to maintain a package or two in the near
>future, but this means that it cannot really expect to have the same
>marketing clout as a `commercial' distribution like RH. Nevertheless, we
>could attract a lot more users if the CDs were anything like as up-to-date
>as what is on the mirrors. Debian may well be at the cutting edge, but a
>lot of users are unable to be as up-to-date, which is frustrating for
>them, a marketing nightmare, and no doubt a pain in the ass for developers
>who would no doubt like people to be able to use the latest fruits of
>their labours. Indeed Debian seems to have a reputation amongst the Linux
>users in Cambridge of never releasing anything. I know this isn't fair,
>but I can see how that image has occured.
>
> There isn't an easy answer though - it's probably worth trying to
>release more CDs (or perhaps a script to enable people like me to make cd
>images from the version of hamm currently on the mirror and give them to
>my friends), but equally we musn't fall into RH's trap of releasing buggy
>dists. (although the support here is free :) ). This of course means that
>testing needs to be done, which takes time. I wonder whether more users
>could be involved in testing - it's not obvious how to do this from the
>website, and so I'm reluctant to volunteer without knowing how much is
>involved, though it seems to me that every hamm system is a potential
>testbed - and if this potential is harnessed then perhaps we could get
>releases out more rapidly.
As I understand it the releases are numbers x.y.z X changes only for
gross structure change, loss of backward compatiblity etc ... such as
a.out-> elf and libc5 -> libc6 etc... Y changes when enough bug fixes,
upgrades accumulate to make a new release, new install scripts, new
packages, new user shells etc. But if the time between releases is too
great then make alot of 'z' increments. Here you update packages that are
out of date (but not packages that would break other packages if they
changed unless you update the 'broken' ones too and tie them together.
This would keep debian from getting too long in the tooth. IE: don't keep
versions of LyX or Emacs in the distribution that are 2 or 3 major versions
old. Update the offical CD often, bumping that 'z' number to indicate this
is not a new 'full' release, but has updated packages and maybe some new
ones. Redhat does this 'silently', such as adding netscape to 5.0 after
the fact. Even if you just 're-burn' the cd image to match the current
'stable' path in the ftp site from time to time. But somehow make a note
of it so the cd repackers pick up on it.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: