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, -- Charles Lepple clepple at gmail
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 > > >
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
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, >