Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 173.246.101.161 as permitted sender)
	client-ip=173.246.101.161;
	envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; 
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CAL0fb62WFvqFFDm=jvgG2B2Gyxj_uV_Ex-drjYHMVh08F0YrNQ@mail.gmail.com>
References: <CAL0fb62WFvqFFDm=jvgG2B2Gyxj_uV_Ex-drjYHMVh08F0YrNQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 06 Sep 2011 23:51:05 -0400
Message-ID: <1315367465.2697.4.camel@BMThinkPad.lan.bluematt.me>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Testing commits
Precedence: list

On Tue, 2011-09-06 at 20:32 -0400, Alex Waters wrote:
> I am working on the following to create a stable build environment for
> testers:
> 
> 
> - Build bitcoin 4.0 source in Windows 7
When did it switch from 0.4 to 4.0?
I feel like the user-facing quality of the software should not be
over-emphasized when it really is very beta in quality.
> - Create a package of the build dependencies, and upload to SF
https://bitcointalk.org/index.php?topic=4750.0 (a bit outdated, but it
should still work fine)
> - Write up instructions for the build process
https://bitcointalk.org/index.php?topic=5851.msg86700#msg86700
If the instructions were updated with fresh links/versions/etc, they
should work 100%.
> 
> 
> x Build bitcoin 4.0 source in Ubuntu 11
> - Create a package of the build dependencies, and upload to SF
No package needed, just apt-get the relevant packages?
> - Write up instructions for the build process
doc/build-unix.txt is (though in some cases somewhat ubuntu-specific)
quite good IMHO.
> 
> 
> I am also compiling a list of commits that need to be tested in both
> environments. If you can think of any priority commits that need
> testing, and/or have a test case for them - please link the pull
> request in a response
>  to https://github.com/alexwaters/bitcoin/issues/2
If you are feeling lazy, I can convince jenkins.bluematt.me to churn out
windows and ubuntu builds almost identical to those that will come out
of gitian (ie the same build as the official release builds) if you
want.
Something like the current jenkins scripts could also be easily hacked
up to automatically sanity-test pull requests as they come in and catch
common errors (or just sanity failures).
> 
> 
> This is not a requirement for pull requests, but will help process the
> important/easy ones a lot faster. I would love to discuss other ways
> of prioritizing pull requests, but this seems like it can get the job
> done for the time-being.
> 
> 
> -Alex Waters