[Nut-upsdev] Reviving the Windows port of NUT

[Charles Lepple]

On Jan 15, 2014, at 10:18 AM, Emilien KIA wrote:

> 2014/1/15 Charles Lepple <clepple at gmail.com>:
>> 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.
> 
> I am just fixing some bugs and implementing some minor
> windows-specific features.

Hmm, okay. Hopefully we can get more help from others on the list.

>> 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 see that. I has also seen that many windows dedicated branches exist.

The original Git windows_port branch in networkupstools/nut-archive should match the state of the SVN branch. That was converted with reposurgeon, and the SVN merges were turned into proper Git merges. If you want a clean starting point that also includes history, that would be my suggestion.

Fred's later commits (as well as your two most recent commits) could be cherry-picked from the windows_port_2013-11-13 branch, since that branch contains several rebased copies of the original windows_port branch.

>> 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.
> 
> Fred was not at ease with git. I think we must review these branches,
> review the code and look at reworking a clean windows-dedicated
> branch.
> I also think we must prepare a clean plan about Windows. Fred has done
> a great job to investigate the windows port and has started develop
> it, and almost did it.
> 
> But he had in mind that specific code had to be less intrusive as possible.
> The code if full of #ifdef , too many IMHO. They make parts of code unreadable.
> I think we should plan what modification we can do to make specific
> developments isolated and functional part easier to understand.

Agreed.
> 
>> 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).
> 
> I just test Windows Nut on my desktop. I wish Windows branch will
> compile and will be reintegrated in buildbot ASAP.
> 
>> 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.
> 
> I am not a fan of "discarding" history.
> I prefer working harder to rebase and rework the branch.

The rebasing needs to happen only after the merge points, or else the merges would need to be done by hand.

>> 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.
> 
> Yes but it is done once.
> 
>> To do that, we will want to have a good test environment.
> 
> Of course.
> 
>> Can we use the Eaton Windows buildslave for this? Or is there another machine we can use to test this branch?
> 
> AFAIK, there is not Windows buildslave in Eaton. Arnaud ?
> But we perhaps can work to set it up ?


This is the one I was thinking of. I will add it back to the waterfall:

http://buildbot.networkupstools.org/public/nut/buildslaves/eaton-win2003server-x86

-- 
Charles Lepple
clepple at gmail