Re: Finding an improved release process.
>>>>> "alexeijh" == alexeijh <alexeijh@westnet.com.au> writes:
alexeijh> Desktop vs server. I currently use debian for my
alexeijh> desktop/development workstation. I'm sure most of you do
alexeijh> too. Do we need to identify and specify that we are for
alexeijh> desktops just as much as servers?
Definitions:
reliability[remote]: Prevent breakage that disallows logging in
remotely and fixing the problem. The worst case is if all current
network connections die. The nest most serious case is if current
connections are OK but new connections cannot be created. Even if
the problem can be fixed, if the power fails at the wrong time...
reliability[obvious]: Prevent breakage that is not immediately
obvious; This is annoying. Perhaps the worst case example is if it
prevents the computer from rebooting (making it fall into the
previous category). Upgrading kernels is potentially risky in this
regard. If a vital service shuts down without the administrator
knowing about it, this could be annoying even if the problem is
extremely easy to fix.
reliability[hard]: Prevent breakage doesn't fall into either the above
categories but is not easy to fix in, lets say under 5 minutes by
a reasonable competent administrator.
reliability[easy]: Prevent breakage doesn't fall into either the above
categories, i.e. it is easy to fix.
security[local]: Security of the local machine only.
security[network]: Security of the network; may require virus scanners
and firewall to be up-to-date. Obviously this implies security[local].
A server is more likely to be administrated remotely. It is more
likely to have remote Internet access (even if filtered via a
firewall). As such, the highest priorities, in order highest to
lowest, IMHO, are:
* Connectivity. Obviously it needs to work with whatever interfaces
the site requires, including (if required) IO cards that require
non-free software. This may require newest software in certain
cases. In other cases it may complicate the process of upgrading the
kernel (e.g. if non-free kernel drivers must be rebuilt).
* reliability[remote]
* reliability[obvious]
* reliability[hard]
* security[local]
* security[network]
* reliability[easy]
* up-to-date: Not an issue except as required for above points.
(note: an yucky implication here is that reliability might be more
important then kernel upgrades even if the kernel upgrade would fix
known security issues).
A desktop server on the other hand is more likely to be used by end
users. I can think of two categories:
NOVICE USER
* reliability[obvious]
* reliability[hard]
* reliability[easy]
Doesn't want to have to fix breakage, and may not be able
to. Breakage, no matter how minor might send some novice's straight
to other distributions/OS.
* security[local] (security[network] may or may not be an issue)
Upgrading to latest security tools might get neglected.
* up-to-date: May want latest software package X, particularly if
latest software is needed to meet requirements or if friends use
latest software.
* reliability[remote]: generally not an issue
EXPERT USER:
* security[local]
* security[network]
* up-to-date: Probably wants latest software for everything, but only
if time permits (especially if breakage likely).
* reliability[remote] (possible depending on usage)
* reliability[obvious]
* reliability[hard]
* reliability[easy]
Prefers not to have to fix breakage, but is capable of doing
so. User typically has direct console access, meaning boot problems
can be fixed on-site and network problems can be fixed on-site.
Just my thoughts, probably with a strong bias towards my experience. I
have defined 3 different categories of users. I have deliberately
avoided making any comment on how well Debian currently meets the
requirements of these users.
Also take note of the way I have juggled around the priorities for the
different users.
This probably isn't the only way of categorising users of Debian, but
rather it is to provoke discussion...
I think it might be most important to work out the requirements before
trying to decide a solution.
--
Brian May <bam@debian.org>
Reply to: