2016 03 31 TSC Minutes

Hyperledger Project

Technical Steering Committee (TSC) Meeting

Hyperledger Project - Technical Steering Committee (TSC) 03.31.16.mp4

March 31, 2016 (7:00am -8:30am PT)

F2F at Linux Foundation Collaboration Summit & via GoToMeeting

TSC Members

Resources:

• Github:  www.github.com/hyperledger
• Wiki:  https://github.com/hyperledger/hyperledger/wiki
• IRC:  #hyperledger on freenode.net (has Meetbot)
• Public lists:  lists.hyperledger.org
• Slack:  hyperledgerproject.slack.com/signup (email tbenzies@linuxfoundation.org for access)
• Information on the TSC Members can be found at https://www.hyperledger.org/about/tsc

Agenda

• Proposal for merged codebase
• Linux Foundation IT/Tools Discussion

Proposal for merged codebase

• Chris Ferris:  After close of last week’s Technical F2F, we agreed to bring forward proposal to the TSC this week
• https://docs.google.com/document/d/1XECRVN9hXGrjAjysrnuNSdggzAKYm6XESR6KmABwhkE/edit
• Proposing to formally incubate the merged codebase that emerged from last week’s F2F and formally evaluate through the incubation process where it builds and we can have a release.
• Project sponsored by Chris Ferris (IBM) and Tamas (DAH)
• PoC resulted from Hackathon
• Team proposed set of high level next steps articulated in proposal along with another set of tasks to get to point of mature implementation
• This was proposed as a incubation project
• A question had come up if other projects could come forward with proposals -- answer is yes.  If others have proposals, bring them to the TSC.
• Resources -- IBM and DAH are both committing FTEs to this.  Binh, Tamas, Robert, Sheehan would be initial maintainers.
• Questions / Comments
• Q:  Is this effort of only IBM/DAH, or community?
• Not just IBM/DAH… it is the Hyperledger Community.
• Q:  Can you establish a set of guidelines or documentation to help people that are new and want to get up to speed to help?
• Yes, this can be part of initial work.  Will add initial next steps to create this.
• Q:  Number of stages?  i.e. incubation and then?
• Previously discussed a project lifecycle proposal (not yet finalized).
• https://docs.google.com/document/d/1asqGu-6xlldY4uwmnkgJs3uhqUDa_wCdv9-cGUEEIOY/edit#
• Q:  Hackathon was great -- but, concern with word “incubation”... it feels premature to start down this path.  Proposals need to be vendor neutral. This was a hackathon… let’s continue to experiment and turn into a proposal before it can be incubation.
• CF:  Incubation is the first step.
• ST:  There was a proposal… we worked on this during hackathon.  At this point, we move to incubation.
• MD:  We shouldn’t be gateing and creating barriers for getting incubation and ideas to start.  This is different than a standards effort. Others are free to bring proposals as well. This method is similar to every major open source project.
• HM:  May be a matter of semantics.  Need to make code easier to use.  Shouldn’t be wedded to a single architecture.  People seem to agree on what we need to do, but maybe arguing about terminology.
• MB:  This is not _the_ codebase.  This is _a_ codebase that will be evaluated at a future point.  Want to understand what this evaluation will entail and what efforts are setting this criteria?  Lastly, feels like proposal is code without an understanding exactly what it is being proposed. Architecture is extremely high level… want to understand how these components will be deployed, made available, etc.  What is being proposed architecturally? That said, in favor of making code work, in parallel.
• CF:  We need to aggressively work on evaluation criteria.  We can make that part of the proposal. That said, we need to get code into the HLP project that everyone can start collaborating on.  If someone else wants to do a proposal that we incubate side-by-side, it is welcomed!
• SL:  What are we accepting?  Maybe we accept parts of architecture and break into separate projects?  Right now it seems we are accepting entire OBC architecture as a proposal
• CF:  This is a place to start from, not an end result.
• RGB:  Struggling to understand how to contribute to process.  It is becoming clear that he needs to understand what we think an end state could be.  I disagree that there will ever be one correct codebase… different architectures for different requirements.  If the intention is that we get to one codebase, then we need to agree on the problem we are trying to solve. Or, if the vision is that there are several sister projects addressing needs, that is possible too.  When we talk about eval process, need to address this.
• CF:  May be a problem of semantics.  We are not selecting a code base.  Requirements, use cases, etc. will all shape what we build.  This is like starting with a lump of clay. Just want to start a process of getting people to collaborate and working together.
• Murali:  In favor of merging code bases.  Maybe we come up with a target architecture and identify different components and note which components come from which proposals.
• CF:  Yes. Other people may come forward with ideas of better member services (for example)... this is exactly what we want to do.  This is just a lump of clay to evolve.
• PD:  If you have another idea, put a proposal forward.  Competing ideas lead to innovation.
• CF:  OpenStack, for example.  Someone may want to refactor a component.  Get others to collaborate with them.
• EM:  Maybe noting that this is one project being moved into incubation, but it is not intended as the _only_ foundation.
• CF:  Correct.  But, people need to bring proposals.
• ST:  Help us and others understand the initial proposed code… need a 101 description which would help everyone put it on a broader development base.
• DV:  Sounds like a lot of violent agreement.  A lot is semantics. Doesn’t see how moving this to incubation conflicts with any points above or what happens next or someone makes a different suggestion.
• TB:  There are advantages to this merge.  DAH comes from bitcoin angle, IBM comes from more general angle.  This is pragmatic merge.
• MB:  What does accepting proposal mean?  1) we give it a label that it is incubation status.  2) give it a spot on the hyperledger github. What else? What changes?
• CF:  Bring under HLP umbrella and it goes under the governance of the project.  It would be moved from the independent repository. This would put it under governance to engage and accept work from others.
• MB:  In terms of process, it sounds like the real difference under HLP label, set of guidelines for code review, commitment, licensing, community, contributions, etc.
• CF:  Successful at hackathon with getting different companies to collaborate.  There can be other proposals. But, important that we start engaging and collaborating as community.
• CA:  How about we accept the proposal into incubation, but make sure there, in this repo, there is further clarity that a) we are hoping for further proposals and incubation projects, that b) this isn't not a base at this time, and c) that as the first in there are incomplete understanding of goal end state and are waiving requirements of the proposal process of having a well defined scope as we don't know scope yet.
• ALH:  Suffering by lack of common understanding of what it means to be in incubation.  Project Lifecycle doc could have solved this. This document needs more work. Need to finalize work of lifecycle doc and publish on web.
• ACTION:  Christopher Allen and Mic Bowman suggest verbiage for readme for how we characterize this
• MD:  Need to think in long term.  Putting up gates in front end for proposals may create challenges.  Focus more on getting out of incubation, as opposed to getting into incubation.
• RGB:  Good point.  This makes the readme clarification important.
• Primrose:  There are multiple proposals.  Why are just IBM, DAH, Blockstream as an incubator?  How does Ripple or others become incubating?
• MD:  Those were statements of proposed contribution.  Please put forward a proposal for incubation.
• CF:  It sounds like people are ok, but stuck on semantics.
• RJ:  Would be good to have an Architecture WG
• Ram will lead the WG, Hart will help.
• Ram to circulate note on mailing list with more details and call for volunteers
• VOTE -- Proposal with modifications from Stefan (accessible for new people), also added from Mic (TSC will work in parallel on incubation, graduation, etc. criteria)... Mic/Chris A. to collaborate on clear section in readme that describes exactly what this is).
• Vote passes unanimously with the 9 TSC members present.

Linux Foundation IT/Tools Discussion

• Steve Westmoreland, Linux Foundation CIO
• Gerrit is helpful in controlling to make sure there is a review process and any comments/questions can go back to the contributor, if necessary.  Code management and review.
• Would also like to have a working session on infrastructure.
• Linux Foundation will assign a release engineer.  Also, anyone that wants to work on CI, please let us know.
• ACTION:  Chris Ferris to send a request to the list.

Evaluation Criteria for Incubation to Mature

• MB:  Expect to come out of the requirements workgroup.  Will talk to Patrick Holmes on this.
• CA:  Had put out a call for an Identity Subgroup.
• ACTION:  LF to add an Identity mailing lists.
• MD:  Note that LF IT team is working on slack/mailing list integration