On Tue, Jan 8, 2013 at 8:28 PM, Ben Reser <b...@reser.org> wrote: > We seem to be having trouble getting releases out the door and the > delay is almost always related to Windows votes. > > Consider the following data: > Release Planned Actual Unix vs Windows > 1.6.19 10 Sep 2012 21 Sep 2012 7 days > 1.7.7 09 Oct 2012 09 Oct 2012 1 day > 1.7.8 17 Dec 2012 20 Dec 2012 6 days > 1.6.20 04 Jan 2013 ?? 4+ days > > Windows Voters: > Paul Burba > Johan Corveleyn > Ben Reser > Mark Phippard > Bert Huijben > > The Unix vs Windows column indicates how many days after the last Unix > vote was reached did the Windows vote get to 3. 1.6.20 hasn't hit the > required votes for Windows yet but it will be at least 4 or more days > since we're on day 5 since Unix has been ready to release. > > Windows Voters Unix Voters > Paul Burba 4 C. Michael Pilato 3 > Johan Corveleyn 4 Philip Martin 4 > Ben Reser 1 Ben Reser 1 > Mark Phippard 1 Branko Čibej 4 > Bert Huijben 1 Stefan Sperling 2 > Julian Foad 1 > > The numbers after the names is the number of releases they voted in. > This also doesn't count people who were RM'ing. > > I'd say that the problem is worse for 1.7 but I suspect that 1.7.7 is > an outlier for some reason. However, I hope that it's clear that we > have a problem getting releases out due to Windows testing. > > I think flat out the problem is that building on Windows is just a > pain. I remember it took me several days to get a working build > environment so I could be the last signature on 1.6.19. Unfortunately > I can't be the last vote on the more recent releases because I've been > the RM. > > There are several possible solutions to this problem. > > 1) We could lower the votes required for Windows. It seems like we > are able to consistently get 2 votes, it's the 3rd that is often the > problem. If you look at the last several releases often the 2 votes > for Windows come in before the 2nd or 3rd vote for Unix. If you > assume each of the 6 votes needed come from different people that > means you need 6 different people to approve a release. I'm not sure > how many active contributors we have but 6 could easily be half. It's > not necessary that all 6 be given by different people, but in practice > this is what happens. Another point is we only require 3 votes for > Unix when there are many platforms that fall under that category, some > of them quite different. Most of the time the 3 Unix votes ends up > being done on Linux, sometimes even one distro of Linux. On the flip > side of this most of our client users are using Subversion on Windows, > yet we do most of our development on Linux. So maybe we are justified > in the current voting setup. But changing the voting would help > resolve the release delays. > > 2) I could stop RM'ing. That throws another person in the pool of > people who test on Windows. Right now there are 5 people who have > tested on Windows in the last 4 releases, I'm one of those people. In > comparison Unix has a pool of about 6 people (with me being the person > who's overlappping). I do think the actual pool of potential Unix > voters is larger than is suggested by the last 4 releases, since there > are quite a few names not included that I know could have voted if > necessary. However, I'm not thinking of anyone included in the > Windows pool that is known to have a working Windows build setup. It > would give me a chance to spend some time on hopefully improving the > situation since I'd be dealing with Windows for the release voting > (which I haven't done since 1.6.19). > > 3) WANdisco has non-committers building and testing the release > candidates in order to provide binary packages. I'd imagine > Collab.net has something similar going on since they also provide > Windows binaries. We could start accepting the results of these tests > as a vote with a committer validating that the tests were done with > the proper source package and provides the signature for the vote. > You can look at this as not really any different than a committer > committing a non-committers code change. > > These three above responses might help provide some more immediate > solutions but they don't really resolve the problem. So let's look at > some options that solve the root problem. > > 4) One of the major problems with building Subversion on Windows is > building the dependencies. We could build and package a pre-built set > of dependencies that we provide for download. A script could be > written that downloads this, puts everything in the right place and > makes it relatively easy to build for Windows. This could probably be > done as a short to moderate term project. > > 5) We could rewrite the build system to use something like CMake in > order to provide a truly cross platform build system. This would > probably take quite a bit of time. But would probably be worthwhile > for the project in the long term. > > I expect the decision we make will be some combination of the above, > not just one of these choices.
I actually have my own git branch of subversion trying to make a cmake system for windows but not having much time on this atm. Cmake just simply works better for windows. And if developers want to use xcode on mac etc. Although i am just an emacs nut and gcc developer in my spare time i dislike this gen-make.py. Cmake would give a standard system across versions of subversion also because 1.7 and 1.6 are awkward and hard to automate on windows. The real problem overall is gen-make.py isnt very clear because it requires path to certain things in a very specific way and apache and libdb (because you need to make inc/ lib/ bin/ and add all these to MSVC never mind all other depends) are hard to build on windows but thats not subversions fault.
