[Nut-upsdev] Reviving the Windows port of NUT

[Emilien KIA]

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.


> 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.

> 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.

> 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.

> 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 ?

>
> Thanks,
>
> --
> Charles Lepple
> clepple at gmail
>
>
>