Alex Waters [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-09-07 to 2011-10-20
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 02:34:15

- reply

📅 Original date posted:2011-10-20
🗒️ Summary of this message: Proposal to use wiki pages for Bitcoin Improvement Proposals (BIPs) with author having final word in editing wars. Amir suggested as BIP editor. Discussion on potential BIPs to be held on bitcoin-dev mailing list. Gavin started proposals on GitHub's Wiki feature.
📝 Original message:>
>
> • I propose that BIPs be wiki pages, with a social convention that the
> Author gets final word if any editing wars break out.
ACK
>
• If he's willing, I propose that Amir take the role of BIP editor.
>
> ACK
> • I think bitcoin is still too small to have a specialized
> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
> discussed either here or on the bitcoin-dev mailing list.
>
ACK
As for what Nils mentioned on using GitHub's Wiki feature, Gavin seems to
have started a few proposals at
https://github.com/gavinandresen/bitcoin-git/wiki. I think this is the right
direction to head in, and a composite list of similar proposals could be
maintained on their own repository (to maintain separation from the core
Bitcoin repo.)
-Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111020/2efa61f4/attachment.html>

2023-06-07 02:34:15

- reply

2023-06-07 02:28:21

- reply

📅 Original date posted:2011-09-20
🗒️ Summary of this message: Refinement needed to avoid abruptly closing pull requests without warning. Suggest automated warning emails and detailed rebase walkthroughs to avoid outdated issues.
📝 Original message:> We need to avoid a user/contributor experience of: "my pull request
> was abruptly closed with no warning"
I agree, I definitely want to go about this in a non-jerk way. I would
be pissed if I spent hours coding something, and it was put on the
back burner and eventually closed (especially without notice). The
wording and process could use refinement.
> Contributors might not track the state of the tree on a day-to-day
> basis. Thus, following the example of bugzilla.redhat.com and many
> other "tracker" applications, outdated issues first initiate an
> automated warning email -- usually by adding a comment to the bug
> report -- that describes the policy, why the policy (closing outdated
> reports) exists, and how to avoid automated report closure.
I can definitely do this, and give a wordy notice before I start the
timer. I will write up a message that links to a rebase walkthrough
(any suggestions? I think Gavin has one somewhere...), I would like it
to be more detailed than GitHub's walk-through.
My main reason for pushing this is that it will help clear out some of
the older pulls/issues that exist right now. I'm hoping that in the
future, the QA process will be good enough that pulls/issues won't
fall behind from lack of testing - and the timers will be used very
sparingly. It should only be in place to sort out the pulls/issues
that the majority doesn't want included in the client.

2023-06-07 02:28:14

- reply

📅 Original date posted:2011-09-19
🗒️ Summary of this message: Proposal to add timers to pull requests and issues on Bitcoin's GitHub repository. Outdated requests will be closed after 15 days to avoid stagnation.
📝 Original message:I would like to propose adding timers to the pulls / issues:
https://github.com/bitcoin/bitcoin/pull/523
"From time to time a pull request will become outdated. If this occurs, and
the pull is no longer automatically mergeable; it will be closed after 15
days. This can be avoided by rebasing the commit. Pull requests closed in this
manner will have their corresponding issue labeled stagnant.
Non-bug issues with no commits will be closed after 15 days from their
last activity.
Issues closed in this manner will be labeled stale.
Requests to reopen closed pull requests and/or issues can be submitted to
QA at BitcoinTesting.org. "
This will help cut down on the abandoned / stagnant pulls and issues.
It will also focus attention on priority items, and phase out unwanted changes.
Sidenote: QA at BitcoinTesting.org is working, unlike QA at Bitcoin.org
-Alex

2023-06-07 02:27:59

- reply

📅 Original date posted:2011-09-19
🗒️ Summary of this message: Participants discuss the naming of a proposal to enhance Bitcoin, with suggestions including BIP, PEB, and BER. Concerns are raised about confusion with BitTorrent EPs.
📝 Original message:I'm sorry that I misunderstood the protocol being separate from the
client in regard to 'BEPS'. It definitely makes more sense that way.
As far as naming; I vote BER pronounced Beer.
On Mon, Sep 19, 2011 at 12:57 PM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> New 'standard' transaction forms would be perfect candidates for BEPS.
>
> I think we aught to have a formal proposal to separate the protocol
> version from the client version, too.
>
> --
>
> Does anybody besides me think maybe we should name them something
> other than "BEP" ?
>
> I'm worried we'll regret it in two years when a google for "BEP003"
> takes you to the BitTorrent EPs instead of the BitCoin EPs.
>
> Maybe "BIP" == Bitcoin Improvement Proposal
> or "PEB" == Proposal to Enhance Bitcoin
> or "BER" == Bitcoin Enhancement Request
>
> I think I like "BIP" (PEB sounds like a diet soda, and I don't know
> if BER should be pronounced "bear" or "beer").
>
> I generally don't care about names, but it seems like a little
> planning now might save some confusion later. And I don't want the
> BitTorrent folks to get pissed off at us for 'stealing' their acronym,
> either.
>
>
> --
> --
> Gavin Andresen
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:27:50

- reply

📅 Original date posted:2011-09-19
🗒️ Summary of this message: Alex suggests maintaining an index similar to Python's PEPs for organizing Bitcoin development. He recommends continuing with the current system and considering alternative organization voting around the time of 0.5 release.
📝 Original message:http://www.python.org/dev/peps/ is a good reference if you're
interested in seeing how PEPs work in action. I would be more than
willing to maintain a similar index if that's what people want.
Something to note is that Python does not use Git or GitHub (AFAIK).
So we would need to update 001 to reflect the BEP involvement with
Git, or transition away from it completely (which I discourage).
My full-time experience as a project manager with Basecamp, Redmine,
Teamlab, Pivotal Tracker, SVN, and custom VC has taught me that it is
hard to find a good solution for the organization of the development
life cycle. Having examined Bitcoin for the past three weeks, it is
hard to discern the willingness to implement meta changes.
It looks like Git/GitHub is working, but not ideal for everyone. My
opinion is that there will always be a missing feature in VC systems.
My major gripes with GitHub are the lack of prioritization options,
voting system, and reporting/metrics.
Gavin has asked me to research various O/S projects, to see how they
are doing things. I have been focused mostly on organizing a pull
testing system, and learning the testing process - but I can spend
more time on meta organization if that is in demand. It would be
helpful to me if I could hear some feedback on what needs changing,
and how important it is.
My recommendation is that we continue with the current system, but
plan alternative organization voting around the time of 0.5 release.
This could be an alternative to GitHub, or a supplement, or neither.
Seeing as we are still in Beta, I don't believe there needs immense
structure until we approach 1.0. The PEP system is outstanding, and is
clearly a solid alternative/supplement to consider.
-Alex

2023-06-07 02:27:38

- reply

📅 Original date posted:2011-09-21
🗒️ Summary of this message: Jeff's suggestion for a stable kernel release is good, but there's a bigger QA problem. Testing and bug fixing are needed for a stable 1.0 release.
📝 Original message:I think what Jeff has said is ideal for a stable 1.0 or 1.1 release of
a kernal. I also think it's absolutely the direction we should be
heading in, but not this afternoon. The desire to keep a 0.4.x stable
branch is a symptom of a bigger QA problem, one that I am attempting
to address in general.
Gavin has reminded me to test, test, test. I implore anyone who clicks
the pull button to not only test their code, but write down how they
tested it. The issue tracker is somewhat out of control, and my
opinion is that a stable branch is not going to fix it.
This stage of development can be agitating, as you implement code in
the wild - it is outpaced or broken easily. The sooner we can get a
robust QA process to hammer out bugs, and process pulls - the closer
we are to a stable 1.0 release.
Please contact me if you would like to help contribute to the bug
hammering - I promise that we can find ways to make it
interesting/challenging. (working on a zapper too!)

2023-06-07 02:25:46

- reply

📅 Original date posted:2011-09-14
🗒️ Summary of this message: Gavin Andresen suggests that forking changes should not be introduced until there is a compelling reason, and should be saved for when they are necessary.
📝 Original message:On Wed, Sep 14, 2011 at 4:28 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> What do other people think? I think it is too high risk for too
> little benefit and shouldn't be done until we have a really compelling
> reason to introduce a forking change.
Could we bundle this and potential future blockchain-splitting changes
- to implement them in a major release (down the road)? Or save them
for when they are very necessary?
TL;DR shelf it until needed, have it written just in case.
-Alex

2023-06-07 02:25:46

- reply

2023-06-07 02:23:38

- reply

📅 Original date posted:2011-09-08
🗒️ Summary of this message: Pull request #506 on the Bitcoin repository has been closed until further changes or consensus is reached.
📝 Original message:https://github.com/bitcoin/bitcoin/pull/506 has been closed pending
additional commits or a change in consensus.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110908/8bf319dc/attachment.html>

2023-06-07 02:22:56

- reply

📅 Original date posted:2011-09-09
🗒️ Summary of this message: A new team member introduces themselves, expressing a desire to learn and contribute. They seek guidance and offer to make the development cycle easier.
📝 Original message:I expect that I will make a lot of mistakes, and probably ask too many
questions - but I hope you can bear with me.
I've been trying to keep a low profile as I get better acquainted with the
project. I'm clearly in the company of some very smart people - and would
like to keep it that way.
I've tried to do my research on the main contributors, and it seems that
Matt is the only one to escape my Google stalking. If you have any questions
about my background - feel free to inquire.
It's difficult to ascertain what needs QA work first, so any guidance or
suggestion is appreciated. I'm available via social networks, email, phone,
fax?, IM, IRC, etc. Let me know your preference, or don't and I'll bugger
off.
I'll try to stay out of the way, and do my best to make the development
cycle easier. Let me know if I'm stepping on toes, or being annoying. I
won't be offended.
As for the commit testing, I want to have an idiot proof solution to get as
many people testing as possible (eventually). With code like this, I think
it's better to go full-auto with the ACKs.
-Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110909/2cfd1924/attachment.html>

2023-06-07 02:22:46

- reply

📅 Original date posted:2011-09-06
🗒️ Summary of this message: Professional is creating stable build environment for testers by building bitcoin 4.0 source in Windows 7 and Ubuntu 11, creating package of build dependencies, and compiling list of commits for testing.
📝 Original message:I am working on the following to create a stable build environment for
testers:
- Build bitcoin 4.0 source in Windows 7
- Create a package of the build dependencies, and upload to SF
- Write up instructions for the build process
x Build bitcoin 4.0 source in Ubuntu 11
- Create a package of the build dependencies, and upload to SF
- Write up instructions for the build process
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110906/e5b96ef8/attachment.html>

2023-06-07 02:20:03

- reply

📅 Original date posted:2011-09-10
🗒️ Summary of this message: Alex requests a pull request and testing plan to close wx issues and avoid qt issues. Excited to get it in.
📝 Original message:Can you please submit a pull request and testing plan? If these already
exist, can you please link them here?
I'm exciting to get this in, as it will close the wx issues. (and hopefully
not bring on too many qt issues)
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110910/414ee27d/attachment.html>