On Jan 15, 2014, at 10:18 AM, Emilien KIA wrote: > 2014/1/15 Charles Lepple <[email protected]>: >> 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@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
