* On 2017 28 Oct 18:36 -0500, goli...@dyne.org wrote: > I was just looking at some old threads over at DUF and ran across this: > > https://www.debian.org/vote/2017/platforms/lamby > > Haven't given it a thorough reading but what I did see I found interesting . > . .
Thanks for that. I've not kept track of Debian's politics for about a year so Chris' name did not create an association in mind--probably a good thing! I hope he succeeds in getting the new maintainer process more friendly. I may have entered the process years ago, but I don't live close to a group of Debian Developers nor do I work in an industry that would facilitate me going to their conferences, etc. I understand Debian's chain of trust, but for me it was a non-starter. It is problematic because Debian Policy does not permit newer packages to enter Stable after the freeze. A case in point was the trustedqsl package used by amateur radio operators. IIRC, this was just before Jessie (maybe Wheezy, no matter) went Stable. The ARRL (the organization that requires use of trustedqsl to upload log data to its Logbook of The World Web site), mandated the use of a newer version that rendered the version in then Debian Stable obsolete. A ham running Debian Stable had to make a choice, either compile trustedqsl from source or dist-upgrade to either Testing or Unstable to get a new enough version. I filed a bug, but that was moot as precious policy would have been violated. Yesterday another amateur radio package, WSJT-X, released its latest version, 1.8.0. The version in our Jessie repository, 1.1, is far too old to be useful. So I built it from source and installed it to /usr/local. It builds and runs just fine on Jessie libraries. But there is little point making a .deb as it's "untrusted". Meanwhile, I jumped in a offered to update and maintain several out of date Slackbuilds scripts hosted at http://slackbuilds.org for Slackware 14.2. No hassle, just make the contribution/pull request, let the maintainers examine the scripts/changes, and away we go. As a maintainer of an upstream software package for amateur radio, I get patches all the time. I look them over and apply them or make minor corrections or work with the contributor to get the patch where it should be. It seems to me that Debian could adopt something similar that rather than maintainers that upload binary packages, the Debian specific scripts are uploaded, examined, and committed and then the binary packages are built by Debian's trusted infrastructure. Also, when it can be demonstrated that an out of date end user application package is harming the usefulness of Stable for a given task that a policy exception should be made that allows an update, not just send users over to the backports repository either, which requires that a DD be interested enough to create the backported package. After 18 years of using De*an, I've encountered some warts that should be addressed. This is why I think that derivatives sometimes get more attention as Chris laments. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us
signature.asc
Description: Digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
