Speaking from a Windows admin POV, there are already active security
holes in XP that Microsoft has announced and also announced they will
not be patching, as of this date.
XP is dead, the 32 bit Windows code like 2003 is dead, and time spent on
reviving it is time that could be spent on writing a clean 64 bit
Windows version of NUT.
Ted
On 1/15/2014 6:19 AM, Charles Lepple wrote:
Emilien,
just saw your commit in Buildbot for testing some Windows changes.
That's great that someone is working on this again! We have had a few
users ask for updates to the 2.6.5+ version of NUT for Windows.
The problem is that we do not have a good branch in Git to work from.
The windows_port branch got rebased, but since it has merge commits,
it is a bit of a mess.
I apologize for dropping the ball here - I offered to Fred that I
would try and rewrite some of the windows_port branch history, but
never got around to it. I don't have a Windows box to test on, and
the XP/2003 Buildbot slave can't properly build from Git (so I
removed it from the waterfall).
We probably need to just discard the old history of the windows_port
branch, and rebase it on 2.7.1, but there are a number of changes
that we will want to manually merge. Basically, if someone makes a
change to all of the drivers on a given branch at that time (for
example, something on master between 2.6.5 and 2.7.1, but not on
windows_port), and the windows_port branch gets rebased, we need to
look at that commit and do the same thing to any other drivers that
were added between 2.6.5 and 2.7.1. To do that, we will want to have
a good test environment.
Can we use the Eaton Windows buildslave for this? Or is there another
machine we can use to test this branch?
Thanks,
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
