Running tests on windows

[Matt Mackall]

On Tue, 2012-03-27 at 09:58 -0400, Chuck Kirschman wrote:
> On 3/22/2012 10:20 AM, Matt Mackall wrote:
> > On Wed, 2012-03-21 at 23:41 +0100, Angel Ezquerra Moreu wrote:
> >> On Wed, Mar 21, 2012 at 4:25 PM, Mads Kiilerich<mads at kiilerich.com>  wrote:
> >>> On 03/21/2012 04:09 PM, Angel Ezquerra Moreu wrote:
> >>>>
> >>>> I think that hackable mercurial was a very big step forward to make it
> >>>> easier for us windows users to start to contribute. The fact that the
> >>>> test suite cannot be run as-is is yet another obstacle that I wish was
> >>>> not there. Even though thanks to your efforts it is now possible to
> >>>> run part of the test suite on windows, it is not quite as easy as
> >>>> running it on Linux yet.
> >>>
> >>>
> >>> Really?
> >>>
> >>> The test suite _do_ run as-is when you have MSYS. But granted, it requires a
> >>> posix environment with sh and other tools, something that "all" unix systems
> >>> have preinstalled.
> >>
> >> That is exactly what I meant, plus the fact that apparently not all
> >> tests run on windows, even on MSYS.
> >>
> >>> Many Unix users have had problems running from source (and thus running the
> >>> test suite) because they didn't have a Python development setup and thus
> >>> couldn't build Mercurial from scratch.
> >>>
> >>> I don't see much of a difference.
> >>
> >> Well, on Windows you need Python _plus_ a posix environment.
> >>
> >>> The necessary MSYS packages are easy to install, but they could probably all
> >>> be bundled in a 'Hackable2' zip. Hint hint ;-)
> >>
> >> :-) Let's see if I get it to work first!
> >> Does the MinGW license allow that kind of repackaging?
> >>
> >>>> In my opinion there are two things that could make it easier for
> >>>> windows users to contribute to mercurial:
> >>>>
> >>>> 1. Let the test suite run on cygwin, with as little workarounds and
> >>>> custom setup steps as possible.
> >>>
> >>> Why is cygwin better? Is it just because you happen to like it and already
> >>> have it installed?
> >>
> >> You are partly right. It would be more convenient for me since I
> >> already use Cygwin. It is also my experience that Cygwin has a greater
> >> user base,
> >
> > Umm, no. Indeed, more people may have a Cygwin install than a MinGW
> > install, but that's not what we care about at all. We primarily care
> > about testing the _normal Windows API/environment/libraries/filesystem_
> > and we don't care about supporting Cygwin's emulation weirdness much at
> > all because their are vastly more generic Windows users. Thus using
> > MinGW's bash to run shell scripts in an otherwise Windows-like
> > environment is much more useful.
> >
> >> For example, I just followed the instruction on the HackableMercurial
> >> wiki page and I managed to be able to run the tests. That is great,
> >> but then I tried to run the patchbomb test, to verify a change that I
> >> just did to the patchbomb extension and unfortunatelly that particular
> >> set of tests does not work. That would not have happened if I was
> >> using Linux. That may partly explain why there are less Windows
> >> mercurial hackers.
> >
> > Really, I think it's cultural. Our user base looks like this:
> >
> >   Windows>>  Mac>>  Linux
> >
> > And our developer base looks like this:
> >
> >   Linux>>  Mac>>  Windows
> >
> > And that situation has persisted for ages. If the potential Windows
> > contributor/user ratio was even a tenth of what it is on Linux, this
> > list would be dominated by Windows hackers and we would have blown past
> > all these obstacles years ago. But instead it took six years before a
> > frustrated project leader who doesn't even have a copy of Windows
> > finally got around to building HackableMercurial using Linux + Wine.
> >
> > And on Mac, there aren't really any excuses. Mercurial installs are
> > "hackable" out of the box, the test suite runs, and there's a standard,
> > free compiler. There should be enough Mac developers out there that I
> > never have to lift a finger to fix Mac bugs and yet we manage to make
> > releases like 2.1.1 where no one notices it doesn't compile until after
> > it ships.
> >
> I've really wondered about the lack of Windows developers.  From my 
> perspective it is the reception that we get early on.  My coworker and I 
> have submitted a few patches; some were ignored, and others got the 
> response "hopefully X will comment on them" which never happened.  It 
> really felt like the project wasn't interested in Windows-only patches.

No, the problem is that you haven't fully grokked the practical
realities of a volunteer-based project. There's exactly one person on
this project who's paid at the moment and between patch review, bug
triage and feature development, there's approximately 10x more work to
do than he's likely to get done. I try to ensure that every patch gets
at least a response, but even that's a stretch sometimes.

And that means everything else happens on a volunteer basis. We have
-only volunteers- (ie people with full-time responsibilities doing other
things) who are experts on your particular NTLM/SSPI/IIS issues. So when
you throw your patch over the fence, odds are quite good that unless
it's "obviously correct" so non-experts like me can review it, it's just
going to sit there unless you proactively engage people.

-- 
Mathematics is the supreme nostalgia of our time.