Big benefit of (B) is same release cycle as solr, perhaps same version, piggy-back on releaseWizard (perhaps not even any new steps), auto test with same version.. Guess this is kind of a mono-repo kind of choice. It's different for solr-operator, different tech, built to support many solr versions etc.
But short term my vote is still (A) Jan > 13. jan. 2022 kl. 16:47 skrev Houston Putman <[email protected]>: > > Thanks for listing these out David. > > I think for the sake of 9.0, I choose (A). For 10.0 and beyond, I think I > would prefer (B). You are right that if it is in it's own repo (C) it will > not get much looks/releases. Which could be fine, but I think it's nice that > it has to release with every Solr version for now (and therefore must > maintain compatibility). > > Either way for (B) or (C) it needs its own set of artifacts & docker file, > but I agree with Jan, I don't think those would be particularly hard to solve. > > - Houston > > On Thu, Jan 13, 2022 at 6:57 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > It's kind of a free-rider for sure, and a convenient one :) > Ideally I'd like (C), but pragmatically for 9.0 I vote for (A) unless someone > steps up with lots of energy :) > > If we did C, there'd be a separate release artifact in CDN alongside > solr-operator. <https://dlcdn.apache.org/solr/> The Dockerfile would be slim > and simple, and the image could be pushed to apache/solr-prometheus-exporter, > no need for "official" image? > > Jan > >> 13. jan. 2022 kl. 02:56 skrev David Smiley <[email protected] >> <mailto:[email protected]>>: >> >> The inevitable rename of the "contribs" module to something else ( >> https://issues.apache.org/jira/browse/SOLR-15917 >> <https://issues.apache.org/jira/browse/SOLR-15917> ) will be a time for us >> to move the prometheus exporter somewhere else, as it is not a >> module/package within Solr; it's an independent service with its own >> dependencies; one of which is SolrJ. It does not depend on Solr-core or >> such internals as it once did. >> >> I just want to list some options here; perhaps there is another or a >> variation. I suppose the last option is maybe the best but ultimately >> someone would need to step up to the task. If nobody steps up (not me!), >> then (A) will get done; it's very easy. >> >> (A) The least effort is merely to move it somewhere else in our directory >> structure. If it's still under /solr, like /solr/prometheus-exporter, then >> definitely very minor effort & impact. >> >> (B) More effort is to move to the top level of our source repo to distance >> itself further from the Solr server. But that probably means it would not >> be in our distribution, which also means it would not be in Solr's Docker >> image? We could write a Dockerfile easily enough, I'm more unsure of how to >> publish it and how much effort that is. >> >> (C) Even more effort is to outright move it to a new ASF git repo; to >> arrange for CI (or just rely on GitHub Automation?). I'm unfamiliar with >> the effort in all that. I could help with extracting source history in >> initializing the git repo so we don't lose that. There is also the need to >> add a Dockerfile and to publish it. The beauty of this is that it can have >> its own release cycle! That means very few releases in practice. Although >> it means extra work for actually doing these releases (voting, >> release-manager steps, publishing), instead of a free ride on the Solr >> release train. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> <http://www.linkedin.com/in/davidwsmiley>
