Re: Maintenance of Solr's official Dockerfile

[Marcus Eagan]

Hi Jan,

Thanks or the update, and thanks Jan from Martijn for the donation! :)

I think that regardless of what the community decides to do with the
docker-solr repo, a good first step would be to add a Docker folder to the
Apache repository that contains a base Dockerfile and a README. In that
README, users can be directed to the location of the docker-solr repo,
wherever that may be, or leverage the Dockerfile in the  Apache repo as a
starting point for building their own image.

Two cents,

Marcus




On Sun, Jan 5, 2020 at 3:52 PM Jan Høydahl  wrote:

> Hi,
>
> The Lucene project is asked to take over maintenance of the official Solr
> Dockerfile that ends up on Docker hub (located in
> https://github.com/docker-solr/docker-solr). We have received a Software
> Grant from current maintainer Martijn Koster who has done a fantastic job
> together with a few committers maintaining it.
>
> I think it makes a lot of sense for the project to more tightly support
> Docker and ensure a good experience running Solr on Docker.
>
> This email thread is to discuss what that may look like and how we should
> transition the current code into the project.
>
> As a first step we invite all committers and contributors who use Docker
> to get involved, checkout the current docker-solr git repo, try building
> the images, submitting PRs etc. I have started doing this myself and have
> submitted a few PRs.
>
> Next step would be to agree on how we bring the current code into our
> project and ASF repos in the best possible way. Questions that arise are:
>
> 1. Are we allowed to maintain ASF code in a non-ASF repo? If not, how do
> we transition to an ASF git repo?
> * Can it be a sub folder in our main repo or does it need to be a
> separate repo?
> 2. How will the current build/test/publish process need to change?
> * Can we continue using travis for CI?
> * Do we need to talk to Docker folks to change repo location?
> * Should publishing of new Docker be a RM responsibility, or something
> that happens right after each release like the ref-guide?
> 3. Legal stuff - when we as a project file a PR to update the official
> solr docker images, are we then legally releasing a binary version of Solr?
> Technically it is Docker CI that build and publish the images, we just
> initiate it…
> Do we know any other ASF project that maintain their own official
> docker image?
> 4. Practical things - change README, NOTICE, header files, wording etc
>
> I have opened https://issues.apache.org/jira/browse/SOLR-14168 as an
> umbrella issue for tasks that spin out from this email thread discussion.
>
> Jan Høydahl
>


-- 
Marcus Eagan

Maintenance of Solr's official Dockerfile

[Jan Høydahl]

Hi,

The Lucene project is asked to take over maintenance of the official Solr 
Dockerfile that ends up on Docker hub (located in 
https://github.com/docker-solr/docker-solr 
). We have received a Software 
Grant from current maintainer Martijn Koster who has done a fantastic job 
together with a few committers maintaining it.

I think it makes a lot of sense for the project to more tightly support Docker 
and ensure a good experience running Solr on Docker.

This email thread is to discuss what that may look like and how we should 
transition the current code into the project.

As a first step we invite all committers and contributors who use Docker to get 
involved, checkout the current docker-solr git repo, try building the images, 
submitting PRs etc. I have started doing this myself and have submitted a few 
PRs.

Next step would be to agree on how we bring the current code into our project 
and ASF repos in the best possible way. Questions that arise are:

1. Are we allowed to maintain ASF code in a non-ASF repo? If not, how do we 
transition to an ASF git repo?
* Can it be a sub folder in our main repo or does it need to be a separate 
repo?
2. How will the current build/test/publish process need to change?
* Can we continue using travis for CI?
* Do we need to talk to Docker folks to change repo location?
* Should publishing of new Docker be a RM responsibility, or something that 
happens right after each release like the ref-guide?
3. Legal stuff - when we as a project file a PR to update the official solr 
docker images, are we then legally releasing a binary version of Solr?
Technically it is Docker CI that build and publish the images, we just 
initiate it…
Do we know any other ASF project that maintain their own official docker 
image?
4. Practical things - change README, NOTICE, header files, wording etc

I have opened https://issues.apache.org/jira/browse/SOLR-14168 
 as an umbrella issue for 
tasks that spin out from this email thread discussion.

Jan Høydahl