And you can source build the current version from source on pretty much anything, thus negating any value of distro centric packaging . . . On September 10, 2017 4:20:49 PM CDT, Greg Vickers <daehenoc at iinet.net.au> wrote:>I'll take this hit: Dutchman01, why should there be a new version >released? Is there a significant problem with the current version, or >major functionality that is missing? > >Releasing a new version for the sake of an updated version number isn't > >a reason for releasing an update. > > >On 11/9/17 1:56 am, Dutchman01 wrote: >> >> Hello all, >> >> I request a new NUT release as current dates back to March 9, 2016: >> NUT 2.7.4 >> >> The fact stays that not all distro?s use latest snapshots/commits >from >> github dev tree. >> >> So please do release a new up to date version please. >> >> Thank you >> >> Dutchman >> >> >> >> _______________________________________________ >> Nut-upsuser mailing list >> Nut-upsuser at lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser-- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170910/093b4466/attachment.html>
On 11/9/17 1:56 am, Dutchman01 wrote:> > I request a new NUT release as current dates back to March 9, 2016: NUT 2.7.4 > > > The fact stays that not all distro?s use latest snapshots/commits from github dev tree. >Not all of the distros have moved to 2.7.4, either... As Sam alluded to out on the list (are you subscribed?), if you have a specific issue (such as the one addressed by the libusb-1.0 branch), let us know and we can help you build packages for your distro that include the patches you need. If you just want the latest version, note that the tarballs that you can get from http://buildbot.networkupstools.org (check for links on the Debian builders) are very similar to releases - we use the same `make distcheck` procedure to build and test what we can (without real UPS hardware) as when we build an "official" release. I was going to push for a new release that includes the libusb-1.0 branch, and then I found some issues in the Git history that we need to resolve before merging (see discussion at https://github.com/networkupstools/nut/issues/300 ). Arnaud has also been busy lately, and I am in the midst of trying to move the server that includes, among other things, buildbot.networkupstools.org. That said, let us know if you have specific issues that might have been solved post-2.7.4. On Sep 10, 2017, at 5:27 PM, Tim Dawson wrote:> And you can source build the current version from source on pretty much anything, thus negating any value of distro centric packaging . . .While this is true for many packages, I think this is a bit of a stretch for a tool like NUT when it is being used to shut down a system. Barring the inevitable bug that creeps in, I think the distros are in a much better place to fix integration problems with their shutdown scripts. Sam's suggestion of adding newer NUT sources to existing Fedora RPMs seems like it would reap the benefits of both the distro integration and the newer NUT features and bug fixes.
Charles Lepple writes:> On 11/9/17 1:56 am, Dutchman01 wrote: > > > > I request a new NUT release as current dates back to March 9, 2016: NUT > 2.7.4 > > > > > > The fact stays that not all distro?s use latest snapshots/commits from > github dev tree. > > > > Not all of the distros have moved to 2.7.4, either... > > As Sam alluded to out on the list (are you subscribed?), if you have a > specific issue (such as the one addressed by the libusb-1.0 branch), let us > know and we can help you build packages for your distro that include the > patches you need.Not everyone who asks this is going to have the dev knowledge to build their own custom package. Especially when the package in question is based off a non-default git branch. Especially when the aforementioned git branch won't even build on one's current distribution, due to a makefile issue[1]. Occasionally these kinds of requests come from sysadmins, and others that do not have a development background. I wouldn't assume that every sysadmin would know how to grab a particular git branch, look inside their distribution's existing nut version to see what it does, attempt to replace the existing package with a new tarball, figure out why it didn't work, and then fix the Makefile. Pushing out a defined release will encourage distributions to update to it, expanding the usage of the new code, increase feedback, and make it easier for some to update to the new code base. [1] One of the outstanding pull requests. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170911/9677d5ed/attachment.sig>