Hi Devs, do you have an estimate for a new release date? We want to deploy linux boxes which will include support for the newly contributed phoenixcontact_modbus driver. As we would like to create a package for both CentOS and an embedded Linux device we have, we would prefer if the package was based on a official release. If 2.7.5 is not coming soon (say 1 week) do you have a suggestion of a more stable 2.7.4-x commit to base our packages on? Best Regards, -Spiros -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170601/b767504e/attachment.html>
On June 1, 2017 9:32:34 AM GMT+02:00, Spiros Ioannou <sivann at gmail.com> wrote:>Hi Devs, >do you have an estimate for a new release date? We want to deploy linux >boxes which will include support for the newly contributed >phoenixcontact_modbus driver. As we would like to create a package for >both >CentOS and an embedded Linux device we have, we would prefer if the >package >was based on a official release. > >If 2.7.5 is not coming soon (say 1 week) do you have a suggestion of a >more >stable 2.7.4-x commit to base our packages on? > >Best Regards, >-SpirosHi, I'd say that nowadays with CI testing and real peer reviews of every PR, every state of upstream/master branch is pretty good. In project that I'm part of, we regularly rebase our fork of NUT over the upstream du-jour and this does not induce breakage. Of course, this way I can speak only for quality of the aspects our project does use daily (as is, or extended) - such as the core stuff, the nut-scanner, and networked snmp and netxml drivers, and systemd integration for the most part. We also happen to do much of the recent years' innovation in these areas and backport it to upstream... in part, egoistically - so we have even more testing and less codebase deviations to track :-) I suggest your project does the same, because you can't really know how well drivers and other bits behave on different hardware until you expose them to different use-cases. But if the bits you want are in upstream/master - they most probably already worked at least once for somebody interested ;) My 2c, Jim Klimov -- Typos courtesy of K-9 Mail on my Redmi Android
Thanks for the info Jim. On 2 June 2017 at 07:52, Jim Klimov <jimklimov at cos.ru> wrote:> On June 1, 2017 9:32:34 AM GMT+02:00, Spiros Ioannou <sivann at gmail.com> > wrote: > >Hi Devs, > >do you have an estimate for a new release date? We want to deploy linux > >boxes which will include support for the newly contributed > >phoenixcontact_modbus driver. As we would like to create a package for > >both > >CentOS and an embedded Linux device we have, we would prefer if the > >package > >was based on a official release. > > > >If 2.7.5 is not coming soon (say 1 week) do you have a suggestion of a > >more > >stable 2.7.4-x commit to base our packages on? > > > >Best Regards, > >-Spiros > > Hi, > > I'd say that nowadays with CI testing and real peer reviews of every PR, > every state of upstream/master branch is pretty good. In project that I'm > part of, we regularly rebase our fork of NUT over the upstream du-jour and > this does not induce breakage. > > Of course, this way I can speak only for quality of the aspects our > project does use daily (as is, or extended) - such as the core stuff, the > nut-scanner, and networked snmp and netxml drivers, and systemd integration > for the most part. We also happen to do much of the recent years' > innovation in these areas and backport it to upstream... in part, > egoistically - so we have even more testing and less codebase deviations to > track :-) > > I suggest your project does the same, because you can't really know how > well drivers and other bits behave on different hardware until you expose > them to different use-cases. But if the bits you want are in > upstream/master - they most probably already worked at least once for > somebody interested ;) > > My 2c, > Jim Klimov > -- > Typos courtesy of K-9 Mail on my Redmi Android >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170605/7fbe0311/attachment.html>