:: Re: [Dng] Plan for Devuan to use Mo…
Góra strony
Delete this message
Reply to this message
Autor: T.J. Duchene
Data:  
Dla: 'Nate Bargmann', dng
Temat: Re: [Dng] Plan for Devuan to use Mozilla products as is


-----Original Message-----
From: Nate Bargmann [mailto:n0nb@n0nb.us]
Sent: Saturday, March 7, 2015 6:36 PM
To: dng@???
Subject: Re: [Dng] Plan for Devuan to use Mozilla products as is

Unfortunately, this sort of inconsistency toward their definition of
"stable" caused problems in other areas. During the time that Wheezy was
stable a utility used by radio amateurs was rendered out of date as the
organization that provided the utility changed cryptographic keys on the
site the utility was used for so that a newer version was required.
I entered a bug report that a backport of the newer version should be made
available to all users of Wheezy. For various reasons it could not be done
in such a way so that the older version would be replaced automatically.
This was a failure of policy in my opinion as while it's fine to resist
churn for the goal of stability, when a package is unusable due to external
factors it should be upgraded.

I would like for Devuan to consider this sort of corner case in the future
and resist the urge to be so beholden to policy as to make the featured
release unusable for a subset of its users.

- Nate

It's my belief that Debian QA is not what it once was, and will probably
only continue to deteriorate. I remember (I think it was Etch) when the
official sendmail package conf was broken. Since then, my expectations have
fallen even lower. First, we have cornered packages. Then Debian dropping
policy and going rapid release on browsers. In Wheezy on the installer, the
clock never set local time instead of UTC even if you told it to. I've
always had to manually patch it. The latest, now we have systemd mucking up
the works. These are just small things, granted - but they show a
consistent pattern over time, of either developer resources being stretched
too thin or not enough care to perform proper QA.

I really don't want to see Devuan handicapped because Debian screwed
something up upstream. Not only does Devuan not have the manpower to
maintain the huge number of Debian packages, but Debian's own policies
toward management are inconsistent.

With respect to everyone else's point of view on the subject, that is why I
advocate the idea that Devuan should focus on a "core" subset similar to
FreeBSD's approach. Everything else from Debian should be treated as a
rolling release in an optional repository. By having a core subset and
everything else being user hands on, Devuan can maximize the talent that it
has. If Devuan did indeed decide to consider that approach someday, I
would be very interested in helping to create a test case for modifying the
maintenance process to see if it is a viable idea.


t.j.