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.
