Great, didn't see the "help wanted" tag
before. Is it documented in the Wiki for first-time devs to see?
I am not a huge fan of the bot idea, as I think it should be
something the devs do in the moment and second-nature, e.g. "oh,
this seems like a broader issue, I should seek broader input on
it", as stuff can and should move quickly rather than wait for the
Would love to sync with Sawtooth Lake on these practices too.
On 06/24/2016 10:42 AM, Sheehan Anderson wrote:
Completely agree that it's a firehose at this point and too much
information for a person to reasonably track. While I believe
GitHub issues are the best place to hold discussions, I
recognize the same "how to surface the architecture
conversations" problem. I've seen a few major open source
projects on GitHub use a "big picture" label on important
issues. Perhaps we could use the same label and write a bot that
collects these once per week and sends a collection of links to
the mailing list? People could then subscribe to those
particular issues and receive updates via email.
We do have a "help wanted" label (https://github.com/hyperledger/fabric/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
which is similar to the "bite-sized" marker that you describe.
So far this has worked quite well and a lot of people have used
it to pick up work.
Brian Behlendorf ---06/24/2016 03:25:09
AM---So I've been following the firehose from watching the
github issues (feeling foolish for not lookin
Fwd: Re: [hyperledger/fabric] Remove chaincode instance
variables from example chaincodes (#1981)
Sent by: hyperledger-fabric-bounces@...
So I've been following the firehose from watching
the github issues (feeling foolish for not looking there before)
and am loving all the activity. I am concerned, though, that
sometimes important architectural conversations get buried in a
message that only crazy people like me, and those working
specifically on the code in question, are likely to see. The
below is an example (not to pick on anyone in particular).
Follow the link at the bottom for the full thread. I know there
is corresponding conversation going on in the Slack channel too,
especially when there's some disagreement. But I'm wondering if
devs could do a better job of surfacing architecture and deeper
implementation conversation & thinking to this list from
time to time, like the topic below, as a way to tap into the
broader Fabric dev community for what people think, as well as
help folks following along start to get into the rhythm of how
the code works. Thoughts?
Oh, this also reminds me of one of Karl Fogel's best pieces of
advice, something he and others did on the Subversion project.
When there were triaged bugs that we unresolved, but were
assessed by developers as likely to not require siginificant
rearchitecture of the code to solve, but instead are more likely
a simple error, then those issues were marked as "bite-sized", a
signal to new developers that they may want to use these issues
as a good learning experience while the older hands on the
project were focused on the harder issues. Thought on that too?
-------- Forwarded Message --------
I would agree that in general, simple example
chaincodes should not use persistent state. However, even
though there was a bug in the busywork chaincode that caused
unexpected non-determinism, I'm not sure I'm ready to banish
chaincode-local state for chaincodes that are specifically
designed as test programs. For example, one of the planned
future capabilities for busywork was to allow
non-deterministic error injection, which would make use of
chaincode-local state. (A single chaincode instance is passed
information via a query targeting its peer, and on the next
invoke that chaincode instance stores a random or know-bad
value, for example.)
There may also be optimizations for test
programs (or even non test programs?) that require some
knowledge of what is expected in the state, and perhaps cause
information to be reloaded from the state when is there is a
mismatch.I was actually planning to add something like this in
the next busywork chaincode I've been thinking about. This
chaincode loads a very large data structure and its version
number when the chaincode starts. On each invoke, it compares
the latest version number (8 bytes) from the state with its
own cached version number, and only reloads the large state if
they disagree. Obviously the version number is also updated
whenever the large state is modified (which will be a rare
In general, in Go anyway, I don't think you can
stop anyone from storing data in a package-global variable,
and then accessing the variable, even if you make each
chaincode invocation a newly-created object. It is certainly
unacceptable to take the drastic step to reload the chaincode
package binary every time the chaincode is invoked (assuming
Go supported that, which I don't think it does currently).
There is also the file system, network devices, and other ways
to store and access persistent data. Unless we go to a
You are receiving this because you are subscribed to this
Reply to this email directly, view it on GitHub, or mute the thread.
Hyperledger-fabric mailing list
Hyperledger-fabric mailing list