Re: Quilt reboot, and "compound" projects

Hart Montgomery

I think we need to clarify what, exactly, a compound project *is* before we can say whether or not they make sense as projects. 


Does the compound project provide multiple different functionalities that reuse and share a lot of code?  It probably makes sense for this kind of thing to be a single project.


On the other hand, what if the compound project is a collection of different code bases for a similar functionality that don’t have any interconnection?  In this case, it probably makes sense to keep things separate.


I guess what I’m getting at is that I think it should be the level of interconnection between the components/modules/features/functions that should determine whether some collection of code is one project or multiple projects.  We could technically state that, say, Indy is a compound project because it has two “functionally different” libraries Indy-SDK and Indy-Node.  But this makes absolutely no sense due to the interconnection of the two code bases.


Does this make sense?  It’s been a long day of travel so it’s entirely possible this makes no sense.


I am also super-excited for a new interop proposal.





From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Saturday, June 22, 2019 8:14 PM
To: tsc@...
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects


Compound projects feel a bit unnatural to me.


One elephant in the room is whether we can let projects end the lifecycle. I think that’s a really healthy thing for any portfolio.

I’m not so sensitive to the potential loss of name recognition. In this particular case, I don’t [yet] see an interest from the Quilt maintainers in progressing the ILP code. To me that signals the project is at its natural conclusion.


My view of Ursa is that we are still in the storming stage. I think as a team we are getting closer to its definition, but we shouldn’t point to it as a template of a compound project right now. In fact, if ursa turned into a bag of disjoint parts I don’t think it would be successful, but that’s a different thread.


A lot of what defines a project to me is the maintainers and contributor community around it and their shared drive to create a coherent piece of software. If we sideloaded a second code-base with a different set of developers that doesn’t feel like a unified project to me. That feels more like a branding decision that I think is overthinking our incubation stage.


(and to be clear I am very interested to see a new interop proposal and evaluate it on its own merits)




Dan Middleton

Intel Principal Engineer




From: <tsc@...> on behalf of Vipin Bharathan <vipinsun@...>
Date: Saturday, June 22, 2019 at 6:06 AM
To: "tracy.a.kuhrt@..." <tracy.a.kuhrt@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects


Hello Tracy,

If it is different from ILP, what is it? Will there be a doc describing it much like a project proposal. Any technical papers?  Is there code you would like to bring in? 



On Jun 21, 2019, at 10:55 PM, tracy.a.kuhrt@... wrote:

Hi, Chris and other TSC members. 

The item that you are talking about (Helm charts, etc) is not the interoperability project that we want to contribute to Hyperledger. That will be separate discussion at some point in the future.

I had originally suggested we bring our interoperability contribution into Hyperledger Quilt because the TSC was clear when they approved Quilt that they wanted it to grow beyond just ILP to encompass interoperability. I know some people were communicating Quilt as an interoperability project (before we began the reboot discussion) even though it has always been “a Java-based ILP library” with direction from the TSC to be more. There is ton of interest in the ecosystem for interoperability beyond ILP and payments. The Quilt brand is fairly strong in representing “interoperability”. This along with Mark’s point about distinguishing different interoperability projects is something that should be considered when making the decision.  

While the code that we are wanting to contribute is distinct from ILP, it does fall into the interoperability space. When we were discussing this with Adrian, David, Silona, and others, we did see a need for a set of overall maintainers to ensure that the projects that came into Quilt fell into the interoperability space and who would determine where overlap might exist for code sharing. 

Obviously, we will proceed as the TSC decides — be that to continue the process of bringing this under the Quilt brand or bringing a proposal for a new project to the TSC. We are looking forward to the continued discussion and decision. Please let me know if there are further items that I can clarify/answer. 


Join to automatically receive all group messages.