[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: default pin



On Fri, 2006-06-23 at 23:20, martin f krafft wrote:
> also sprach Thomas Walter <t.walter@nefkom.net> [2006.06.23.2302 +0200]:
> > The only instability I see is, you no longer see always the same
> > versions numbers for months/years.  8-)
> 
> Which may be horrific. If you happen to have access to my book,
> I wrote a bit about this in the beginning of chapter 4. Basically:
> 
>   \item[\emph{Software feature stability}]~\\
>   Stability\index{stability!feature} may also refer to the feature set
>   provided by a software. In this definition, stable software does not
>   introduce drastic changes or radical new features from one release to the
>   next. Administrators appreciate feature stability because it allows them to
>   fix bugs with newer versions without risking unwanted changes to the
>   behaviour.
> 

When using Debian and from one stable release to the other then you have
a "drastic/radical" change in features/functionality.
Due to the fact that there may be several major/minor releases from
upstream jumped over while the package lives in
experimental/unstable/testing.
Using backport one can mitigate big steps but profit from improvements
in existing features/functionality. Maybe, new/additional functionality
introduces new bugs, but this risk is reduced by the strict rules of
backports ti use SW from testing only.

What are "unwanted changes"?
"Unwanted changes" by whom?
In general upstream goes forward, not backward and does not release bug
fix versions forever.  Some time after releasing a new stable release,
the previous is dead except for security fixes, which is done longer.
Finally, the decision about what is useful, wanted and should be
available is on the customer and not on the administrator.
Sorry to say that, but I'm working in an environment where I'm faced
with both sides or better with all 3 sides: customer, admin,
developer/upstream.  The customer asks upstream to implement a
feature/functionality and upstream offers something to the customer.
The admin is in the middle watching for security and availability to the
customer.  But the admin cannot patronize the customer or decide for the
customer.  In brief, if the customer wants version x, then the admin has
to provide version x.


> (I am now off to rewrite the laste sentence for clarity)
> 
> Security updates fix bugs but ensure feature stability. Backports
> may fix bugs but does not ensure feature stability.

As the name/definition says, "security updates" fix bugs which are a
security hole, but not bugs in features/functionality.
That's a big difference.  Or implies feature/functional stability to
stay with the current buggy behavior?  At least this I do not know from
cusstomers and do not expact as customer.
And one has to distinguish between external and internal intruders.
Example:
Some SW has a security bug when feed with special input. But this cannot
happen from external.  Most internal users are no intruders.  One task
of an admin is to block intruders from outside.

Cheers,
Thomas




Reply to: