Quilt reboot, and "compound" projects

Brian Behlendorf

Hi TSC, continuing the conversation we had started but didn't have enough time to fully articulate on the call.  So that makes this the "Quilt Update" due for today.

A few months ago, we started discussing the future of Quilt with its current maintainers, as well as with a set of people who had expressed to us an interest in the topic of cross-ledger inter-operability after our call-out for such interest on a number of TSC calls for a "Quilt reboot".  We also had heard of at least 2 new potential packages of code that could come in, addressing "inter-operability" differently, but in highly complementary ways to each other and to Quilt.  So we started to get everyone talking, and talking with each other.  I want to emphasize that the current Quilt maintainers welcomed this discussion and participated actively.

Quilt itself, the Java implementation of the ILP spec, is not dead - it has responsive maintainers and a small but active userbase. But the current maintainers are just out of energy to do more than answer some basic questions or fix security holes if any appeared.  And, it's been tough to get Quilt's users interested in becoming contributors.  There is still lots of work that could be done on Quilt, so it's not complete.  Bugs do get fixed, sources updated.  It hasn't "taken off" nor by itself grown to encompass other potential ways to build bridges across different DLT system, but it's also something that continues to create value, and where if bugs (particularly security holes) are found and come with a PR, that does get attention.  But the two current maintainers had sent a clear message they didn't have time to actively recruit new users or do more than basic life support. So it's an odd state of "quiet, but not dead" that doesn't necessarily deserve being archived or effectively removed from the community, but isn't as active as we'd probably all like it to be.

It was felt that new activity within the same project boundaries but on different code might lead developers and thus improvements into a "quilt-ilp-java". Also, these new projects weren't quite sure whether their boundaries were clearly and firmly separate - that merging their efforts might make sense, possibly in the short term, possibly in the long term.

So instead of just asking "how do we reboot the Quilt project in isolation", the question we posed to this group we had convened was whether the Quilt developers felt there was value to combining all the code together into a single repo, or alternately adding new complementary sub-projects and repos within Quilt, making "quilt-ilp-java" a peer to however many others.  And, whether those projects would connect with each other and find common cause in the same way we hope other sub-projects do already, though absent a major parent project like e.g. fabric and fabric-sdk-*. We also asked the folks on these other projects (like from Accenture, which as Tracy mentioned today on the call has some code they'd like to bring in) whether they felt better being part of a compound project, or would feel better submitting as independently branded new top-level projects or through Labs.  The sense on the call, from what we could tell, seemed to be in favor of putting this together as a sub-projects within a single project still called Quilt, still limited to the scope as approved by the TSC, benefiting from the promotion we've done to date that Quilt is about interop, and hoping that interest in one piece can drive attention or more to another pieces.  It also seemed clear we should take any proposal like this to the TSC for approval, since there was substantial new code potentially coming in, and we didn't want folks thinking that the ordinary function the TSC provides to review large new contributions coming in was being routed around.  Essentially, a TSC vote on the "Quilt Reboot" that included new code and maintainers but adhering to the original scope and ideals, should still be held to the same standards for any new project, with regards to code quality, likelihood for a new community to grow around it, vendor neutrality, and so on.

After the call, I admit, we got busy.  CA team members got sick or went on leave.  The followup to this meeting was on our shoulders to turn into a proposal document for the TSC, and work with the existing Quilt maintainers and these new potential maintainers to make that a compelling proposal, and also coordinate with other TSC a bit ahead of time as we often do with new project proposals so that when they're proposed they have as few obvious issues as possible.  That work progressed slowly. Plus, we were waiting for some of the proposed contributions to actually become available for review.  We are coming back around to this now.  This was one driver for the Chair discussion we just had, as some participants felt it was important that the TSC not feel like they were being handed a hard-to-manage situation with lots of new faces, and it was something the CA's had started to feel would be useful as a formal role anyways.  We didn't want to propose them at the same time conflating the two issues.  With that Chair issue now concluded by the TSC, we are hoping to make a Quilt reboot proposal soon for the TSC's consideration.

Now, meanwhile, there is re-thinking going on about the project lifecycle, and the role of sub-projects within those - we'll have to align with that of course, but we hadn't yet seen in those discussions a reason to stop this proposal.  I think defining the responsibility sub-projects have to their parent/container and then to the TSC is still important of course.  But I didn't sense that the TSC would do away with sub-projects or require them to associate all subs with a parent codebase as a policy matter.  And policing for such activity within established projects is tough anyways.

That's where we are.  While I know Dan M has in general felt uneasy about these sort of thematic "compound" projects (I know I would without some of the constraints I mention above, like TSC approval for new major components), I didn't want the TSC to be asked to consider a proposal for or against such things in the abstract without a live example to consider.  But if the TSC as a whole feels it's important to set a firm policy here, we'll of course go along with that and recommend these projects be submitted independently, and that some reasonable status with the existing Quilt that covers the Java port of ILP be arrived at which still allows its users to report bugs and make occasional releases and new maintainers to emerge.



Brian Behlendorf
Executive Director, Hyperledger
Twitter: @brianbehlendorf

Join toc@lists.hyperledger.org to automatically receive all group messages.