On Tue, Jan 8, 2013 at 8:28 PM, Ben Reser <ben_at_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.
Received on 2013-01-13 12:02:49 CET