toggle quoted messageShow quoted text
I agree with Chris here. I think a tiered system makes a lot of sense, and will enforce some important communication. For instance, suppose I wanted to create (for the purposes of example) an RFC 1149 user interface for Fabric. I should clearly have to have some sort of approval/mild oversight from the core fabric team, even if this is just some form of maintainer sign off/check in every so often. Otherwise, my project could become neglected or really buggy (and misused by unknowing users), or in some sort of worst case, downright malicious (maybe my avian “interface” steals a lot of user information) and there wouldn’t be a ton of recourse without getting the TSC heavily involved.
On the other hand, I’m OK with projects proliferating (if this is done in a responsible manner). I think it’s a good thing to have more projects—it means more ownership opportunities, and thus potentially more involvement by different companies and individuals.
So I think the best way to deal with these sorts of proposals is with a dependency system. I think this is very similar to what Chris is proposing, but a bit more general. Each new project would need to list the projects it depends on in its proposal, which could be one (like a Fabric SDK depending on Fabric) or potentially many (like maybe Cello or Composer in the future). These dependencies could obviously change over time as well. We probably would then want to require (in the proposal) approval from some subset/majority/<whatever> of the maintainers of the projects that the proposed project depends on, and we could additionally require some periodic communication between projects and their dependencies, which could be done without TSC involvement if the higher-level projects wanted. There can also be a mechanism with which maintainers of a higher-level project can deal with a sub-project that has gotten way out of line.
I think a system like this would have a lot of advantages. First, it wouldn’t really inconvenience projects that are already in progress. There already seems to be lots of communication between existing high-level projects and their dependencies, if not a huge overlap of developers, so I don’t think any current efforts would fail the tests we might propose. This also would address the issues that Mic and Dan raised in the TSC meeting this morning; namely, that it’s difficult for the TSC to know enough of the technical details about various sub-projects to be able to assess any sort of technical merit (or even technical need if project structure gets more complicated in the future). Requiring a diverse set of maintainers to sign off on these sub-projects (in a federated consensus style!) would allow unaffiliated folks to have much more confidence in the sub-projects.
Also, I am of the opinion that a flexible dependency list could potentially help mitigate some of the balkanization issues Chris brings up below, as, for instance, projects like Cello and Composer could potentially add more dependencies as they grow. Projects could also be encouraged to have more dependencies as well in certain cases if people think that collaboration should be pushed.
Anyways, I think this is an important topic going forward, and am open to suggestions/questions/comments etc.
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher Ferris via hyperledger-tsc
Sent: Thursday, March 16, 2017 10:59 AM
To: Middleton, Dan <dan.middleton@...>
Subject: Re: [Hyperledger Project TSC] Go Client SDK Announcement
As I noted on the call, it seems we should have a dialog on how we manage this sort of thing going forward.
We could adopt a two-tiered process, one for proposed top level projects and one for proposed "sub-projects" of an existing top-level project.
Top-level project proposals could be handled as we currently do, with a project proposal following the template  reviewed and approved by the TSC. Then, we could have proposed sub-projects of an existing top-level project reviewed and approved for incubation as a sub-project by the set of maintainers of the existing sub-projects within a top-level project.
Pros: it addresses the concerns raised by Mic and Dan about having appropriate context for reviewing a sub-project proposal.
Cons: it might serve to further balkanize the projects, and for such cases as Cello and Composer, the opportunity to identify potential for cross-top-level collaboration might be missed.
Also, we'd want to establish norms for how projects manage maintainers across sub-projects, etc.
I'd welcome other's thoughts here. Maybe a process where a proposed sub-project is reviewed by the project's collective maintainers and in some cases, there is a referral to the TSC. Alternatively, we could have the TSC request that a project's maintainers weigh in on a proposal to the TSC.
I do think that having the TSC weigh the non-technical aspects is probably something we should continue to do.
On Thu, Mar 16, 2017 at 9:38 AM, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:
I think SDK projects as top level projects would be a bit of a departure from what we’ve done for the last year.
Our litmus test has been, does this project exclusively feed to an existing project? If so, then it was folded into that top level project. If it had some generality then it could be considered for a top level project.
In this particular case, Hyperledger Fabric Go Client SDK, the project is only germane to Hyperledger Fabric. It seems to me that community has the best say on the merits of the project and it should be folded in one way or another under the Hyperledger Fabric project.
This policy should also reduce some administrative growth by avoiding a proliferation of top level projects which are not realistically independent.
I would support that. Is the proposal on the proposals page ready for a formal vote, or did you just want some open discussion on it there?
In general I would like to see us move to a mode where the different SDK projects are each full projects within HL, at the same level as the others, with their own maintainers and roadmap, etc. That would allow us to build diverse communities for each, rather than embedded as an informal "subproject" within e.g. Fabric, which could lend towards a smaller number of people being involved and responsible. It also opens the door, if this is the right thing to do, for the SDK to connect to other frameworks - not a requirement, but a possibility once separated. So that would mean Go, Python, Node, Java SDK projects for Fabric. We could even consider the same thing for Iroha's clients. Perhaps that's worth talking about this week.
Thanks for the contribution and discussion, Aleksandar.
On 03/13/2017 11:08 AM, Aleksandar Likic via hyperledger-tsc wrote:
Can this be on the agenda of the next TSC meeting?
SecureKey Technologies Inc.
This is an announcement of the Go Client SDK proposal to the Hyperledger community. The proposal is already posted to https://wiki.hyperledger.org/community/proposals.
We propose implementation of Hyperledger Fabric SDK Design Specification v1.0 with extensions in the Go language. At the moment, there is no publicly available implementation of the Fabric SDK written in Go. We propose to enable both Fabric Clients and Peers to use this SDK.
The primary motivation is to allow programs written in Go to interact with the Hyperledger Fabric as clients, as per the Hyperledger Fabric SDK Design Specification v1.0 athttps://docs.google.com/document/d/1R5RtIBMW9fZpli37E5Li5_Q9ve3BnQ4q3gWmGZj6Sv4.
In addition, some of the new Fabric features require extensions to the Client SDK Specification. We are planning to implement client support for these features and extensions in the Fabric Go SDK, and also contribute to the Fabric client specification.
Some of the new Fabric features that require changes to the Client SDK Specification are:
- ChainCode creating transactions - https://jira.hyperledger.org/browse/FAB-2438 - Ability to create and synchronously execute a new Fabric transaction from user ChainCode.
- Client Request Broadcast to Specified Subledgers - https://jira.hyperledger.org/browse/FAB-2440 - Ability to broadcast a TP Request to multiple subledgers at once.
- Self-Signed TCerts - https://jira.hyperledger.org/browse/FAB-2441 - Ability for the Client SDK to generate self-signed TCerts.
- Handling of Sensitive Data - https://jira.hyperledger.org/browse/FAB-2450 - Ability to mark transactions parameters as “sensitive”.
- Append Only Endorsement - https://jira.hyperledger.org/browse/FAB-1154 - Ability to have endorsements from peers that are not part of the target channel.
- Light Chaincode Event - https://jira.hyperledger.org/browse/FAB-2567 - Ability to send a chaincode event to client without committing a transaction.
We propose to host the Go Client SDK code at http://gerrit.hyperledger.org/r/fabric-sdk-go. The repository would have the following branches:
- master – implementation that is fully compliant with the Client SDK Specification, without non-standard extensions
- extensions – branch with non-standard extensions.
SecureKey is currently mirroring its internal gerrit fabric-sdk-go repository at https://github.com/securekey/fabric-sdk-go. Implementation currently covers all functions present at the moment in Node.JS Client SDK (https://github.com/hyperledger/fabric-sdk-node) except chaincode deployment and chain initialization. We are using this implementation in our development activities. We are planning to eventually implement the full Client SDK Specification, and also plan to keep it up to date with future SDK changes. As it already implements most SDK features, we expect that it will be used for new development by others whose language of choice is Go.
SecureKey Technologies Inc.
hyperledger-tsc mailing list
Executive Director, Hyperledger
hyperledger-tsc mailing list