Hi Carlos,<br>
<br>
I've merged your patch, in the Development tree, with some modifications:<br>
- I kept the compat list for fentonups models. I'll wait for users
feedback to switch these to megatec, as I think there are important
calculation data declared in fentonups, which are not present in
megatec (or am I wrong?)<br>
- I've switched all the remaining compat list references from powermust<br>to megatec (ie Soyntec, ...)<br>
- I've kept the powermust removal. Other drivers will be removed,
during the Development process, but only when we'll be sure that the
support with megatec is fine (a call to users on -dev, and possibly on
-users will be needed)<br>
<br><div><span class="gmail_quote">2005/10/23, Carlos Rodrigues <<a href="mailto:cefrodrigues@mail.telepac.pt">cefrodrigues@mail.telepac.pt</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
...<br>
PS: besides "esupssmart", "blazer", "mustek" and "megatec/powermust"<br>
(which are, for all effects, similar), the drivers "bestups",<br>
"fentonups", "ippon", "masterguard" and "sms" also seem to drive the<br>
same protocol with some variations (seemingly extra commands to<br>
indentify the UPS and stuff like that). Since, AFAIK, this protocol<br>
states that the UPS should output the input given if it doesn't<br>
understand it, it could be possible to make one superdriver unifiying<br>
this protocol (I don't have the hardware though, so this could only be<br>
done with the collaboration of people who do, if they feel like doing it).</blockquote><div><br>
I really like the superdriver (what I call Meta driver is the same).<br>
This is the long approach we have to have (see my QA tasks note on that point).<br>
<br>
</div>There is some work to be done, but calling for drivers authors and users will help a lot...<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 10/23/05, Charles Lepple <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>
> wrote:<br>> You might want to add an entry to the CHANGES file. <br>
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I was under the impression that the responsible for modifying the
<br>CHANGES file was the person who commits the patches. But any way, I<br>attached a patch to change it below.<br><br>> Also, is there a way to ease the upgrade for existing powermust users?<br>> If someone upgrades nut RPMs automatically, and their driver
<br>> disappears, they probably won't be happy. (The top ten results of<br>> Googling for "newhidups" yields one such story for that driver:<br>> <a href="http://weblog.erenkrantz.com/weblog/2005/10/17#breezy-nut">
http://weblog.erenkrantz.com/weblog/2005/10/17#breezy-nut</a> )<br>><br>> Symbolic links to the old driver names, maybe?<br><br>Well, I'm changing this stuff using the development branch. I don't<br>think something like this belongs in a stable branch (it provides no
<br>extra functionality, nor fixes any bugs). So, I don't think forcing<br>users to change one line in a configuration file when upgrading to a<br>new stable series is that much of a big deal.<br><br>But anyway, a symlink seems like a nice way to provide compatibility,
<br>but also poses the question of how many releases to keep it around.<br></blockquote></div><br>see my other post on that topic.<br>
<br clear="all">
Arnaud<br>-- <br>Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt<br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/">http://www.networkupstools.org/</a><br>Debian Developer - <a href="http://people.debian.org/%7Eaquette/">
http://people.debian.org/~aquette/</a><br>OpenSource Developer - <a href="http://arnaud.quette.free.fr/">http://arnaud.quette.free.fr/</a>