Why Nostr? What is Njump?
2023-06-07 02:22:53
in reply to

Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-07 🗒️ Summary of this message: Alex Waters is ...

📅 Original date posted:2011-09-07
🗒️ Summary of this message: Alex Waters is creating a stable build environment for testers by building Bitcoin 4.0 source in Windows 7 and Ubuntu 11. He is also compiling a list of commits that need testing.
📝 Original message: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
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu