<p>Hi Michal and Charles</p>
<p>--<br>
(sent from my eeePad... please excuse my brevity)<br>
Le 10 août 2013 03:04, "Charles Lepple" <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>> a écrit :<br>
><br>
> On Aug 9, 2013, at 7:18 AM, Michal Soltys wrote:<br>
><br>
> > I'm still a bit reluctant to merge it without a bit wider exposure, so if anyone has a possiblity to test it with some apc units - any feedback would be most welcome.<br>
><br>
><br>
> Apparently, a lot of people are using NUT via packages, so:<br>
><br>
>  * users might not want to build from source if things are working<br>
><br>
>  * the packagers might not pick up a 2.7.x dev version, or it might be a while before it gets much use<br>
><br>
>  * users can always fall back on apcsmart-old<br>
><br>
> Not much we can do about the first two points, but if you want, we can put a big warning in the apcsmart-old banner that it will eventually go away, and they should report any bugs encountered with the new apcsmart driver.<br>

><br>
> IMHO, we have to balance the hassle of users upgrading against the burden of maintenance for drivers with such wide arrays of supported hardware.</p>
<p>I'm 2nding Charles: it's the usual chicken&egg game.<br>
I've always applied the transition path as you currently do (new-<driver>, <driver> and old-<driver>), which is somehow the best and only option we have. It should probably be documented in the "New driver" chapter.</p>

<p>Now, if you're not fully confident in a mod, provide an option to fallback to the previous behavior, when easily applicable and making sense.<br>
Otherwise, apcsmart-old is there (up to NUT 3.0 imo).</p>
<p>cheers<br>
Arno </p>