Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-10 🗒️ Summary of this message: A potential ...
📅 Original date posted:2011-08-10
🗒️ Summary of this message: A potential developer expresses frustration with the aggressive rejection of new ideas and lack of support for new developers in the Bitcoin community.
📝 Original message:On Wednesday 10 August 2011 20:57:29 Jeff Garzik wrote:
> > People get itches and they want to scratch them. They aren't paid, so
> > they don't necessarilly want to turn up and be told which part they
> > _should_ be working on. The choice is not "bug fix that Gavin wants"
> > or "new feature that New Developer wants", it is "New Feature" or
> > nothing.
>
> This is true -- though there is value to having a list of "things we
> think people should focus on" for the motivated, and for new people
> interested in tackling a project, but not sure what project to tackle.
My objection is not that such a list exists, it is that potential new
developers are, essentially, shouted down unless they are working on that
list. I cannot imagine that many new developers arrive under those
circumstances.
> A centrally managed development branch on bitcoin/bitcoin.git is not
> the way to do it, however. See the description of linux-next, in my
> previous email, for a more distributed method which can easily be
> layered on top of the existing bitcoin dev structure by any motivated
> volunteer(s).
I don't think I said anything about it being centrally managed. git lets us
store these branches anywhere of course. The fact is that such a branch
exists somewhere.
> Think distributed. :) The community does not need Linus's help
> (linux-next) or Gavin's help (bitcoin-next) to do this. linux-next
I didn't say that it required anybody's help; but it does require a bit of
willingess on the part of the master-branch-owning developers to import from
that branch.
> became so widely used and useful that Linus requires almost all
> changes to be first staged in linux-next.
They key thing with linux-next is that work done on it _does_ make it into
the kernel. Tell me -- how many feature branches for bitcoin are just
sitting as a pull request on github, and are now months old and abandoned
out of disgust by their original authors? Here's another question: why is
it that so many projects have "specially compiled" versions of bitcoin?
Rhetorical question... it's because the official client doesn't do what they
need, and won't accept their patches to add it (even optionally).
I've only been watching this list for a few weeks (since the forum turned
into an echo chamber); but I'm completely depressed by the agressive
rejections of every new idea anyone raises.
Don't believe me? Here's a list of ideas I've had "no, no, no"d so far; not
one of which would have any financial implication at all. Only some of
which would break backward compatibility.
- Extra bits in the service field of the version message to allow nodes
to indicate if they are mining; if they are willing to be seed nodes;
if they relay transactions; if they want relayed transactions.
- getblocks in reverse chronological order so clients can start up quicker
while downloading the blocks in the backround. Ironically I was told
"patches welcome" by someone who didn't reject this one instantly.
- Remove verack, as it's completely unnecessary.
- Query miners for pending transactions
- Application version separate from client version
- A way of requesting block bodies without headers (saving a lot of traffic
for a thin client upgrading)
- Double SHA-256 for a packet checksum? Seriously?
- Sequence number as part of TxIn instead of part of the whole transaction
- Script parameters should be stored outside the script, and reference by
the script. All that ridiculous filtering of the scripts in OP_CHECKSIG
would then go away.
- MSG_DOUBLESPEND... nope
- getblocks to accept MSG_TX and do something sensible
Every single one of those has been shot down by one or more of the main
developers. I'm not a genius, and not arrogant enough to assume that
everything I say is right, but _nothing_? Really? There is no problem that
one of the above addresses?
Given that, what do I do? Hang around and get battered some more, or go
away to my own little corner and work on my own implementation?
You can imagine then that when I read moans about there not being enough new
developers fixing bugs, that I am unsurprised and unsympathetic. I like
bitcoin enough to hover on this list; and offer a view of your world from a
potential developer who was chased away.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
🗒️ Summary of this message: A potential developer expresses frustration with the aggressive rejection of new ideas and lack of support for new developers in the Bitcoin community.
📝 Original message:On Wednesday 10 August 2011 20:57:29 Jeff Garzik wrote:
> > People get itches and they want to scratch them. They aren't paid, so
> > they don't necessarilly want to turn up and be told which part they
> > _should_ be working on. The choice is not "bug fix that Gavin wants"
> > or "new feature that New Developer wants", it is "New Feature" or
> > nothing.
>
> This is true -- though there is value to having a list of "things we
> think people should focus on" for the motivated, and for new people
> interested in tackling a project, but not sure what project to tackle.
My objection is not that such a list exists, it is that potential new
developers are, essentially, shouted down unless they are working on that
list. I cannot imagine that many new developers arrive under those
circumstances.
> A centrally managed development branch on bitcoin/bitcoin.git is not
> the way to do it, however. See the description of linux-next, in my
> previous email, for a more distributed method which can easily be
> layered on top of the existing bitcoin dev structure by any motivated
> volunteer(s).
I don't think I said anything about it being centrally managed. git lets us
store these branches anywhere of course. The fact is that such a branch
exists somewhere.
> Think distributed. :) The community does not need Linus's help
> (linux-next) or Gavin's help (bitcoin-next) to do this. linux-next
I didn't say that it required anybody's help; but it does require a bit of
willingess on the part of the master-branch-owning developers to import from
that branch.
> became so widely used and useful that Linus requires almost all
> changes to be first staged in linux-next.
They key thing with linux-next is that work done on it _does_ make it into
the kernel. Tell me -- how many feature branches for bitcoin are just
sitting as a pull request on github, and are now months old and abandoned
out of disgust by their original authors? Here's another question: why is
it that so many projects have "specially compiled" versions of bitcoin?
Rhetorical question... it's because the official client doesn't do what they
need, and won't accept their patches to add it (even optionally).
I've only been watching this list for a few weeks (since the forum turned
into an echo chamber); but I'm completely depressed by the agressive
rejections of every new idea anyone raises.
Don't believe me? Here's a list of ideas I've had "no, no, no"d so far; not
one of which would have any financial implication at all. Only some of
which would break backward compatibility.
- Extra bits in the service field of the version message to allow nodes
to indicate if they are mining; if they are willing to be seed nodes;
if they relay transactions; if they want relayed transactions.
- getblocks in reverse chronological order so clients can start up quicker
while downloading the blocks in the backround. Ironically I was told
"patches welcome" by someone who didn't reject this one instantly.
- Remove verack, as it's completely unnecessary.
- Query miners for pending transactions
- Application version separate from client version
- A way of requesting block bodies without headers (saving a lot of traffic
for a thin client upgrading)
- Double SHA-256 for a packet checksum? Seriously?
- Sequence number as part of TxIn instead of part of the whole transaction
- Script parameters should be stored outside the script, and reference by
the script. All that ridiculous filtering of the scripts in OP_CHECKSIG
would then go away.
- MSG_DOUBLESPEND... nope
- getblocks to accept MSG_TX and do something sensible
Every single one of those has been shot down by one or more of the main
developers. I'm not a genius, and not arrogant enough to assume that
everything I say is right, but _nothing_? Really? There is no problem that
one of the above addresses?
Given that, what do I do? Hang around and get battered some more, or go
away to my own little corner and work on my own implementation?
You can imagine then that when I read moans about there not being enough new
developers fixing bugs, that I am unsurprised and unsympathetic. I like
bitcoin enough to hover on this list; and offer a view of your world from a
potential developer who was chased away.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com