[Hyperledger Project TSC] Minutes / May 19th, 2016
Technical Steering Committee (TSC) Meeting
May 19, 2016 (7:00am - 8:30am PT)
Deutsche Boerse Group
Richard G. Brown
IRC: #hyperledger on freenode.net (has Meetbot)
Public lists: lists.hyperledger.org
Slack: https://slack.hyperledger.org/ (self-generated invites)
Information on the TSC Members can be found at https://www.hyperledger.org/about/tsc
Welcoming Brian Behlendorf, Executive Director, Hyperledger Project
Action item review
Exit criteria discussion
Action Item Review
TSC representation policy draft (Chris Ferris)
Will complete by 5/26
Whitepaper draft by 5/18 then on 5/19 TSC agenda (Dave Voell)
Will discuss during WG updates
Bishop to work with Binh, Sheehan, and Greg to get HIP busywork Exerciser integrated into fabric
Pull request due to land today
Doodle poll for June (virtual) Hackathon (Todd Benzies)
Doodle poll for July Hackathon (west coast) (Todd Benzies)
Exit criteria doodle pool (Todd Benzies) -- can start discussion during TSC call
Requirements WG (Oleg Abdrashitov)
Concentrating on developing use cases in catalog
Created a dashboards page
Architecture WG (Ram Jagadeesan)
No meeting held this week; will update next week.
Whitepaper WG (Dave Voell)
Whitepaper Draft v0.1 (published May 19, 2016)
Please provide feedback to the Whitepaper working group through our Feedback Form
Request for everyone, especially TSC members, to read through and add edits prior to this draft going to the Governing Board
Identity WG (Christopher Allen)
Minutes from May 18th meeting
Need more work in requirements and use cases around lifecycles of identities, will be working on some docs to share with those WGs
Variety of discussions around possible technologies being deployed elsewhere with real relevance
Selective disclosure and different approaches was a hot topic for the group
May need different identity services and determine what APIs would be needed
Tomorrow is big UN conference on digiital identity http://www.weboftrust.info/
Jeremy S: we came up with list of potential use cases and will be reaching out to Oleg to see how it maps in. As we getting a better sense of dimensions of layers of system -- helps to have a common language to separate out some of these things.
Christopher A: conflation in a variety of areas. Different identity communities call “key holders” vs. “principals”... need to reconcile some terminology issues. Fundamental difference between finance and supply chain workflows. Discussed with Eric Anderson of Bloomberg who will be sharing with Identity workshop some of the use cases that Bloomberg wants to share.
CI WG (Chris Ferris)
Gerrit has been stood up; need some more config and training and then a planned migration from Github to Gerrit
Jenkins is up; but still needs a small amount of confg, should be done early next week
If people want to help with CI, plenty of opportunity to volunteer
Exit Criteria Discussion [thank you to Alice Ma and Bill for the notes below!]
Project must have cultivated a diverse set of contributing members
One of the most important factors
Ensure that membership is > 1
Diversity includes diversity of usage, e.g.: companies that use the technology and servicing the technology. We shouldn't just measure the contributions, we need to take into account the types sizes of companies that can deploy solutions
Must demonstrate some threshold of test coverage.
Some sections of the codebase are more important to cover than others (crypto, security)
We need a yardstick to measure this beyond "we always need more (tests)"
What's a reasonable % of test coverage?
Hard to say because it's different at different levels:
security stuff: upper 90's
business logic: 5 lines of test per 10 000lines of code (?)
Further discussion required
Is this idea related to scale of use in real world?
Appropriateness of requirements met by MVP
Concern: Given that running code wins, is there a risk in putting too many requirements?
Programming practices of security world are difficult to do in an agile way BUT there's still value to the agile paradigm. When it comes to business logic, we could do better than Ethereum smart contracts (15 serious errors per 1000)
HOWEVER: Contracts/chain code (except for samples) are not quite what we're doing
STILL, some things need to be strong, so we do need a high bar (e.g. identity/IBM's new crypto system using keys in a new form)
Project must have real world use
Use by a small supply chain/something that is "real "in some fashion is a criteria for being mature
Real problems: does the code fit into the regulatory requirement?
Test ledgers perpetually running?
Less rigorous definition
Refinement period is necessary for all OS projects:
Ledgers cannot be treated like a service package. Needs to be cross-autonomizationservice?
Can incubate DNS bind and understand how it works as a package
Other projects had continually running test pads to verify cross-organization consistency: not a full-blown production systems
May need to know whether or not it's "transaction-ready"
Has it been audited/blessed by security/crypto community
Has it been used by a regulator
Ensure that there's enough disclaimers so that there's no misunderstandings/legal trouble
What does "maturity" and "incubation" mean from a community perspective?
Should discuss this further outside of the call.
Definition of "mature": is there a separate interpretation of maturity within the Hyperledger organization (vs the interpretation within other OS communities)
Just because something is out of incubation doesn't mean it's not incubating anymore. It means that it's at its beginning, and that more tests and functionality can be added
Should there be a level in between "mature" and "incubating"? Or should this be handled by levels of release? (1.0, 2.0, 3.0, etc)
Does "mature" really mean "mature enough to rely on it in some fashion"?
Proposed definition of "incubation" and "maturity" – "maturity" means that we have agreed that this thing is something we're going to continue to support and develop
"Anchor points": both terms reference a project's participation in the final release of the code base, not in terms of maturity or use of the code IRL
Input from someone (name?):
The "incubation" label is like "beta"
Considerations: Has this project/module proven capable of releases? People maintaining, debugging as necessary, security patches
Look to Apache incubator for how other OSF's do this (they don't require proof of production use)
Should be enough for anyone to test/deploy any of the modules. Documentation should illustrate test cases, demonstrate various test cases
Input from Christopher Allen:
We haven't had discussion on:
Multiple identity system
E.g.: Hyperledger would only have 1 "master" codebase, future iterations will have to reconcile with existing ones
Does one version of a module need to be compatible with existing mature versions for it to be considered "mature"?
Slack channel: archived messages can't be seen
Modes of communication/collaboration: slack, email, conference calls
If we want to use slack, then maybe we should consider getting an enterprise version
Todd and Brian to have a conversation about what we can do to fix
TSC representation policy draft by 5/26 (Chris Ferris)
Doodle poll for June (virtual) Hackathon
Doodle poll for July Hackathon (west coast)
Whitepaper Review on 5/26 call
Slack channel (Todd Benzies and Brian Behlendorf)
Exit Criteria Summary (Chris Ferris)
+1 (415) 412-0310 (m)
|1 - 1 of 1|