[Nut-upsdev] New sub-driver submission process timeframe?

[Charles Lepple]

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>