Solr Devs,
We've slowly been moving into a multi-repository model, and I wanted to
bring some more attention to it and have a more focused discussion. We've
recently embarked upon the acceptance of solr-operator as a distinct
repo[1] under the care of the Lucene (soon to be Solr) PMC. I expect that
there will be more cases of this as we transition additional contribs out
of core, or as more plugins, packages, and integrations mature. Some will
make sense as externally maintained code bases, but I believe other
contributions may benefit our community more as part of the Apache
Foundation.
I think there was a very insightful comment[2] made by GP regarding
adopting a similar model to Apache Commons governance, bringing attention
to it here because I fear it may have gotten lost deep in the thread. Based
on observations of Commons and a few other Apache projects with multi-repo
setups, there thankfully does not appear to be a limit on how many
repositories a PMC can maintain. The size and scope of each individual
repository can vary greatly. I see potential ideas for anything that could
be standalone and not tied to a release cycle (Admin UI, DIH, etc...), or
anything that bridges integrations between Solr and other systems (k8s,
HDFS, etc...).
The risks that new repos face are similar to the risks they would have
encountered as contrib modules, but I don't think they should dissuade us.
Each project would need to start with a champion or sponsor and a
discussion on the mailing list. From there, we can vote to accept the code,
or just the idea if there is no code yet, as a community and create the
repo. As part of a natural lifecycle, if there's not enough momentum or
adoption over time, then we can update the README and docs and "retire"
certain projects. The exact mechanisms can be undetermined for now; maybe
it's a repo rename, maybe it's marking the repo read-only, maybe it's
something else.
The Commons model is that everyone is a committer on everything. There are
other governance models, like Hadoop, with "area committers" who are
limited to the specific repositories they have contributed frequently to.
I'm not sure which model ultimately suits us better, but I think that
leveraging area committers would allow us to recognize and empower
contributors sooner and more frequently. Releases would still need to be
voted on and approved by the singular PMC.
There's no real action items here, it's more of a discussion prompt. If it
looks like we have general consensus to this approach, then I'll start
putting together individual proposals for a few repos to exercise the
process and get more contributions going. I'll probably put the proposals
together even if there's no replies here, but I'd much rather have some
acknowledgement from the community that I'm headed in a sustainable
direction!
Mike
[1]:
https://lists.apache.org/thread.html/rb90f530155dc6edc6f1ccd5f056db1618142fdfcbd32d83f539d984b%40%3Cdev.lucene.apache.org%3E
[2]:
https://lists.apache.org/thread.html/r9965cb693369d927a942f805c134bfeb45c5e80f447ad0fe2f663fae%40%3Cdev.lucene.apache.org%3E
We've slowly been moving into a multi-repository model, and I wanted to
bring some more attention to it and have a more focused discussion. We've
recently embarked upon the acceptance of solr-operator as a distinct
repo[1] under the care of the Lucene (soon to be Solr) PMC. I expect that
there will be more cases of this as we transition additional contribs out
of core, or as more plugins, packages, and integrations mature. Some will
make sense as externally maintained code bases, but I believe other
contributions may benefit our community more as part of the Apache
Foundation.
I think there was a very insightful comment[2] made by GP regarding
adopting a similar model to Apache Commons governance, bringing attention
to it here because I fear it may have gotten lost deep in the thread. Based
on observations of Commons and a few other Apache projects with multi-repo
setups, there thankfully does not appear to be a limit on how many
repositories a PMC can maintain. The size and scope of each individual
repository can vary greatly. I see potential ideas for anything that could
be standalone and not tied to a release cycle (Admin UI, DIH, etc...), or
anything that bridges integrations between Solr and other systems (k8s,
HDFS, etc...).
The risks that new repos face are similar to the risks they would have
encountered as contrib modules, but I don't think they should dissuade us.
Each project would need to start with a champion or sponsor and a
discussion on the mailing list. From there, we can vote to accept the code,
or just the idea if there is no code yet, as a community and create the
repo. As part of a natural lifecycle, if there's not enough momentum or
adoption over time, then we can update the README and docs and "retire"
certain projects. The exact mechanisms can be undetermined for now; maybe
it's a repo rename, maybe it's marking the repo read-only, maybe it's
something else.
The Commons model is that everyone is a committer on everything. There are
other governance models, like Hadoop, with "area committers" who are
limited to the specific repositories they have contributed frequently to.
I'm not sure which model ultimately suits us better, but I think that
leveraging area committers would allow us to recognize and empower
contributors sooner and more frequently. Releases would still need to be
voted on and approved by the singular PMC.
There's no real action items here, it's more of a discussion prompt. If it
looks like we have general consensus to this approach, then I'll start
putting together individual proposals for a few repos to exercise the
process and get more contributions going. I'll probably put the proposals
together even if there's no replies here, but I'd much rather have some
acknowledgement from the community that I'm headed in a sustainable
direction!
Mike
[1]:
https://lists.apache.org/thread.html/rb90f530155dc6edc6f1ccd5f056db1618142fdfcbd32d83f539d984b%40%3Cdev.lucene.apache.org%3E
[2]:
https://lists.apache.org/thread.html/r9965cb693369d927a942f805c134bfeb45c5e80f447ad0fe2f663fae%40%3Cdev.lucene.apache.org%3E