Nut upsdev - Mar 2015 - New sub-driver submission process timeframe?

Faster than I expected, I've become somewhat disenchanted by the openups-usb
driver.

So, if I write my own subdriver for our UPS...how quickly can I expect that it
will be incorporated in some downloadable version of nut that a user can then
use?

The main reason I ask is because I have to include a guide for getting the UPS
to work in Linux.  If I can simply stipulate that they have to download NUT
version 2.xx.xx and the driver will be included, then that makes things a lot
easier than having to provide the driver ourselves along with the procedure for
them to add it to the NUT source, etc.  I'm not talking about in a package,
I mean just a part of the sources that they can download, extract, compile,
install.

I have just under two months to have a guide a customer can use to make the UPS
shutdown their Linux PC.  If that won't be enough time to get something into
the NUT trunk, then I'll have to make-do with the openups-usb driver, and
work our own driver later.

I've read through the 3.9 Source Code Management section of the dev guide. 
I'm much more familiar with svn than git, though I know that needs to
change.

Sincerely,
Rob Groner

Software Engineer
RTD Embedded Technologies, Inc.
ISO9001 and AS9100 Certified
Ph: 814-234-8087
www.rtd.com<http://www.rtd.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150306/a9a4b6e1/attachment.html>

On Mar 6, 2015, at 4:40 PM, Rob Groner <rgroner at RTD.com> wrote:
> So, if I write my own subdriver for our UPS?how quickly can I expect that
it will be incorporated in some downloadable version of nut that a user can then
use?
I'm struggling a bit to provide a useful answer that doesn't sound
dismissive ("sometime soon") but explains what we're up against.
At the moment, the NUT developers are doing this in their spare time, and rather
than being able to estimate time-to-completion like I would in a 9-to-5 software
development environment, my metric is "when it's ready".

I was hoping to get some consensus on the short list of things to resolve before
releasing 2.7.3, and instead I got a request to merge an additional fix that
hasn't been discussed in a while. Arnaud typically does the tarball
releases, and deals with hosting the website-- the latest version in Git is
sufficient for what I need NUT to do.
 
> The main reason I ask is because I have to include a guide for getting the
UPS to work in Linux.  If I can simply stipulate that they have to download NUT
version 2.xx.xx and the driver will be included, then that makes things a lot
easier than having to provide the driver ourselves along with the procedure for
them to add it to the NUT source, etc.  I?m not talking about in a package, I
mean just a part of the sources that they can download, extract, compile,
install.
 
Can I suggest that you provide customers a specific snapshot of NUT (maybe in a
downloads section of your website) that corresponds to your internal testing and
integration efforts, with the understanding that future releases of NUT (source
or binary packages) should be compatible? As new versions of NUT are released,
all it would take is updating the version number in the documentation, and
possibly mirroring a new tarball on your site, to confirm that we haven't
broken anything.
> I have just under two months to have a guide a customer can use to make the
UPS shutdown their Linux PC.  If that won?t be enough time to get something into
the NUT trunk, then I?ll have to make-do with the openups-usb driver, and work
our own driver later.
 
That seems like more than enough time to get a new driver into version control,
but I don't want to give the impression that we cut formal releases for
every new driver. (The goal for releases when Arnaud had more support from Eaton
was at least every six months.) If the driver merges cleanly, and doesn't
involve changes to other parts of NUT, it is easy to incorporate. If not, it
gets put on a branch, which can also have snapshots taken (and we deal with the
merge later).

It's on the order of minutes between when we push commits to GitHub, and
when the autobuilders create a tarball:

   http://buildbot.networkupstools.org/public/nut/waterfall?show=Debian-x64-gcc

(Ignore the Debian part in the URL - the tarball itself is just NUT source code,
generated on a Debian box.)

The snapshots (links below "uploading") are all currently numbered
"2.7.2.6" but the links are different. I've been meaning to add
the short version of the Git revision to the name, but I wanted to wait until
after 2.7.3 is out the door. For a new driver, we can manually bump the version
number.
> I?ve read through the 3.9 Source Code Management section of the dev guide. 
I?m much more familiar with svn than git, though I know that needs to change.
 
Same as with the autoconf stuff-- feel free to ask if you have questions. One of
the advantages of hosting on GitHub was that they provided a SVN gateway. I
think this is still true, so that might be easier for now. An SVN clone of the
NUT repository is sufficient to produce patches with 'svn diff'.

So... not a short answer, but hopefully useful. We don't want to get in the
way of you helping your customers on your own timetable (sort of the "teach
a man to fish..." approach), but I'm not going to make promises for the
project based on limited free time.

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150308/f8313064/attachment.html>

I don't have any problem with pointing customers to a branch they can clone
via git and compile.  But until that's available, I will do what you
suggested (and what my boss has been suggesting for a while) which is to take
2.7.2 and put our driver in it nice and happy and then package that up for our
customer to use.  That will be a more than sufficient means to get our UPS
working until our driver is "officially" included, or at least
available for checkout.

Thanks for the thorough response!

Sincerely,
Rob Groner

From: Charles Lepple [mailto:clepple at gmail.com]
Sent: Sunday, March 08, 2015 9:36 AM
To: Rob Groner
Cc: nut-upsdev at lists.alioth.debian.org
Subject: Re: [Nut-upsdev] New sub-driver submission process timeframe?

On Mar 6, 2015, at 4:40 PM, Rob Groner <rgroner at RTD.com<mailto:rgroner
at RTD.com>> wrote:


So, if I write my own subdriver for our UPS...how quickly can I expect that it
will be incorporated in some downloadable version of nut that a user can then
use?


I'm struggling a bit to provide a useful answer that doesn't sound
dismissive ("sometime soon") but explains what we're up against.
At the moment, the NUT developers are doing this in their spare time, and rather
than being able to estimate time-to-completion like I would in a 9-to-5 software
development environment, my metric is "when it's ready".


I was hoping to get some consensus on the short list of things to resolve before
releasing 2.7.3, and instead I got a request to merge an additional fix that
hasn't been discussed in a while. Arnaud typically does the tarball
releases, and deals with hosting the website-- the latest version in Git is
sufficient for what I need NUT to do.

The main reason I ask is because I have to include a guide for getting the UPS
to work in Linux.  If I can simply stipulate that they have to download NUT
version 2.xx.xx and the driver will be included, then that makes things a lot
easier than having to provide the driver ourselves along with the procedure for
them to add it to the NUT source, etc.  I'm not talking about in a package,
I mean just a part of the sources that they can download, extract, compile,
install.

Can I suggest that you provide customers a specific snapshot of NUT (maybe in a
downloads section of your website) that corresponds to your internal testing and
integration efforts, with the understanding that future releases of NUT (source
or binary packages) should be compatible? As new versions of NUT are released,
all it would take is updating the version number in the documentation, and
possibly mirroring a new tarball on your site, to confirm that we haven't
broken anything.


I have just under two months to have a guide a customer can use to make the UPS
shutdown their Linux PC.  If that won't be enough time to get something into
the NUT trunk, then I'll have to make-do with the openups-usb driver, and
work our own driver later.

That seems like more than enough time to get a new driver into version control,
but I don't want to give the impression that we cut formal releases for
every new driver. (The goal for releases when Arnaud had more support from Eaton
was at least every six months.) If the driver merges cleanly, and doesn't
involve changes to other parts of NUT, it is easy to incorporate. If not, it
gets put on a branch, which can also have snapshots taken (and we deal with the
merge later).


It's on the order of minutes between when we push commits to GitHub, and
when the autobuilders create a tarball:


   http://buildbot.networkupstools.org/public/nut/waterfall?show=Debian-x64-gcc


(Ignore the Debian part in the URL - the tarball itself is just NUT source code,
generated on a Debian box.)


The snapshots (links below "uploading") are all currently numbered
"2.7.2.6" but the links are different. I've been meaning to add
the short version of the Git revision to the name, but I wanted to wait until
after 2.7.3 is out the door. For a new driver, we can manually bump the version
number.


I've read through the 3.9 Source Code Management section of the dev guide. 
I'm much more familiar with svn than git, though I know that needs to
change.

Same as with the autoconf stuff-- feel free to ask if you have questions. One of
the advantages of hosting on GitHub was that they provided a SVN gateway. I
think this is still true, so that might be easier for now. An SVN clone of the
NUT repository is sufficient to produce patches with 'svn diff'.

So... not a short answer, but hopefully useful. We don't want to get in the
way of you helping your customers on your own timetable (sort of the "teach
a man to fish..." approach), but I'm not going to make promises for the
project based on limited free time.

--
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150309/46d6e002/attachment-0001.html>