[Gerrit-CI] Debian Jessie is no longer supported

[Thomas Dräbing]

Dear all,

Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).

Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.

While the images currently used by the CI will work for now, there won't be any updates to the images until this issue is fixed. Due to the way the communication between Jenkins and the slave containers is secured, these images will only work with the production system and not with any test instance or locally, if only one of the images is self-built. A short-term solution might be to tag the current images as legacy images, that will be used to build Gerrit-versions that still require Java 7, while we update the containers to Debian stretch for all other jobs. That means that the legacy containers will not see any updates in tooling anymore. The legacy-images might also stop to work, when the planned update to newer Jenkins versions will happen, but this is hard to tell.

What do you think?

Best,

Thomas

[1] https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html

[Matthias Sohn]

On Wed 27. Mar 2019 at 05:44, Thomas Dräbing <thomas....@gmail.com> wrote:

Dear all,

Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).

Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.

Can we move on and stop building these old versions? How old versions do we support?

While the images currently used by the CI will work for now, there won't be any updates to the images until this issue is fixed. Due to the way the communication between Jenkins and the slave containers is secured, these images will only work with the production system and not with any test instance or locally, if only one of the images is self-built. A short-term solution might be to tag the current images as legacy images, that will be used to build Gerrit-versions that still require Java 7, while we update the containers to Debian stretch for all other jobs. That means that the legacy containers will not see any updates in tooling anymore. The legacy-images might also stop to work, when the planned update to newer Jenkins versions will happen, but this is hard to tell.

What do you think?

Best,

Thomas

[1] https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luca Milanesio]

On 27 Mar 2019, at 09:44, Thomas Dräbing <thomas....@gmail.com> wrote:

Dear all,

Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).

Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.

Yes, that's the reason why we need to keep the older Debian/jessie images.

We have also the Debian/stretch image built which promises a much longer support life: we can start using that for all the Java8-based Gerrit versions (v2.14 and beyond).

While the images currently used by the CI will work for now, there won't be any updates to the images until this issue is fixed.

Not an issue at all for now, we just need to keep the existing ones for now and rebuild only the stretch one.

Due to the way the communication between Jenkins and the slave containers is secured, these images will only work with the production system and not with any test instance or locally, if only one of the images is self-built. A short-term solution might be to tag the current images as legacy images, that will be used to build Gerrit-versions that still require Java 7, while we update the containers to Debian stretch for all other jobs.

Yep. agreed.

That means that the legacy containers will not see any updates in tooling anymore. The legacy-images might also stop to work, when the planned update to newer Jenkins versions will happen, but this is hard to tell.

To be honest with you, we need to start being also a bit stronger about decommissioning older Gerrit versions very soon.

I do know that Gerrit v2.12 and v2.13 are still widely used, but Java 7 is largely unsupported and obsolete now, there is a limit to what we can do in the near future.

What do you think?

Thanks for raising this and triggering the discussion.

Luca.

Best,

Thomas

[1] https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html

[Thomas Dräbing]

FYI:

There is already a proposed change to discontinue with Java 7 and debian jessie by David Ostrovsky, which is quite old by now: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/207554

It proposes to build older Gerrit versions (<= 2.13) with Java 8 with Java 7 as target, but as Luca commented on that change, we would be unable to run tests without a Java 7 runtime.

[Luca Milanesio]

On 27 Mar 2019, at 10:18, Thomas Dräbing <thomas....@gmail.com> wrote:

FYI:

There is already a proposed change to discontinue with Java 7 and debian jessie by David Ostrovsky, which is quite old by now: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/207554

It proposes to build older Gerrit versions (<= 2.13) with Java 8 with Java 7 as target, but as Luca commented on that change, we would be unable to run tests without a Java 7 runtime.

Yes, and on the light of the recent security fix we did on older Gerrit versions, I'm glad we had not discontinued the Java 7 based builds :-)

Keeping both jessie and stretch is a must, with the option that you suggested of "tagging" the legacy jessie for now, until the repos are showing up in the archive distribution of Debian.

Luca.

[Thomas Dräbing]

I found an apt-configuration that seems to work (I still have to test the builds of images downstream of slave-debian). The mirrors will probably still change in the next few days, when also the security-repository is moved. The change can be found here: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/219198

Apparently the jessie packages will be kept in the archive until June 30th, 2020 [1]. So we should be relatively safe until then. Maybe we could also discuss to put this date also as a end-of-support for Gerrit <= 2.13? This would still leave time to update to newer versions.

For now, I would suggest the following plan of action:

1) Maintain backups of debian-jessie based images (Just in case something goes horribly wrong)

2) Apply the fixes to be able to continue to build debian-jessie based images

3) Create debian-stretch based images

4) Move builds that do not require Java 7 to debian-stretch based images

Then:

5) Encourage everybody using older Gerrit versions to update to at least Gerrit 2.14

6) Agree on when to stop support for Java 7 based Gerrit-versions (e.g. June 2020) 

[1] https://unix.stackexchange.com/questions/508724/failed-to-fetch-jessie-backports-repository/508728#508728

[Jonathan Nieder]

Hi,

Thomas Dräbing wrote:

> Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.

Interesting. https://tracker.debian.org/pkg/openjdk-7 tells me a
recent version of OpenJDK 7 is available even for Debian experimental.
Would that be usable here?

Thanks,
Jonathan

[Thomas Dräbing]

I suggested that some time ago, when reviewing this change: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730 .

The question just is, whether the openjdk 7 from the experimental repository is stable enough to be used by the CI.

Since we still have a year until jessy loses its LTS-status, I would rather try to use this year to try to move everybody to a newer Gerrit version, if possible.

[Luca Milanesio]

On 27 Mar 2019, at 15:44, Thomas Dräbing <thomas....@gmail.com> wrote:

I suggested that some time ago, when reviewing this change: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730 .

The question just is, whether the openjdk 7 from the experimental repository is stable enough to be used by the CI.

Agreed. Best to just "tag" the current images for now than risking to have an unstable Java 7 build.

Since we still have a year until jessy loses its LTS-status, I would rather try to use this year to try to move everybody to a newer Gerrit version, if possible.

That would be ideal, Java 7 is largely deprecated and unsupported.

Luca.

On Wed, 27 Mar 2019 at 16:26, Jonathan Nieder <j...@google.com> wrote:

Hi,

Thomas Dräbing wrote:

> Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.

Interesting. https://tracker.debian.org/pkg/openjdk-7 tells me a
recent version of OpenJDK 7 is available even for Debian experimental.
Would that be usable here?

Thanks,
Jonathan

[Luca Milanesio]

On 27 Mar 2019, at 15:46, Luca Milanesio <Luca.Mi...@gmail.com> wrote:

On 27 Mar 2019, at 15:44, Thomas Dräbing <thomas....@gmail.com> wrote:

I suggested that some time ago, when reviewing this change: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730 .

The question just is, whether the openjdk 7 from the experimental repository is stable enough to be used by the CI.

Agreed. Best to just "tag" the current images for now than risking to have an unstable Java 7 build.

Since we still have a year until jessy loses its LTS-status, I would rather try to use this year to try to move everybody to a newer Gerrit version, if possible.

That would be ideal, Java 7 is largely deprecated and unsupported.

$ curl https://review.openstack.org/config/server/version

)]}'

"2.13.12-11-g1707fec"

Are the OpenStack guys happy to upgrade their Gerrit setup or move to GerritHub?

If we drop support for Gerrit v2.13, they'll lose any support from the community for their setup.

OpenStack is a pretty big OpenSource project, not supporting them anymore would be a problem I believe.

@OpenStack guys anyone around to share their view?

Luca.

[Gert van Dijk]

On Wednesday, 27 March 2019 10:44:15 UTC+1, Thomas Dräbing wrote:

Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).

I just wanted to say that using http://snapshot.debian.org/ could be useful here. IIUC, since this is concerning *build* container images only, it's kind of OK to use older versions of packages which may have security issues, because you would never serve a production system from it. Additionally, by setting up a time based snapshot as APT source instead of the regular ones, it also allows you to create fully reproducible Docker-container-image-builds (with some extra scripts like change timestamps, remove logs, see the debuerreotype project). That is actually also how the official Debian Docker images are rolled. I'm not saying we should go to that extend, but it might provide good well-tested pointers to ensure our Gerrit CI containers can always be rebuilt.

(I'd love to help out more with the gerrit-ci project, but I guess I'm limited by my time.)

(By the way, together with Bazel's reproducibility features, this is showing amazing results for how me and my colleagues roll containers for production - they're fully reproducible.)

HTH

[Thomas Dräbing]

On Wednesday, 27 March 2019 10:44:15 UTC+1, Thomas Dräbing wrote:

Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).

I just wanted to say that using http://snapshot.debian.org/ could be useful here. IIUC, since this is concerning *build* container images only, it's kind of OK to use older versions of packages which may have security issues, because you would never serve a production system from it. Additionally, by setting up a time based snapshot as APT source instead of the regular ones, it also allows you to create fully reproducible Docker-container-image-builds (with some extra scripts like change timestamps, remove logs, see the debuerreotype project). That is actually also how the official Debian Docker images are rolled. I'm not saying we should go to that extend, but it might provide good well-tested pointers to ensure our Gerrit CI containers can always be rebuilt.

By now we found a way to avoid using archive.debian.org for everything except openjdk8, which requires jessie-backports. Using snapshot.debian.org also works with a snapshot from beginning of March. Thanks for the hint!

We might even get rid of this in the future, if we do not require build slaves providing both Java 7 and Java 8. Because then we could run all jobs requiring Java 8 using debian-stretch-based images and jobs requiring Java 7 in debian-jessie based images. Then we wouldn't have to install OpenJDK 8 on debian-jessie.

 

(I'd love to help out more with the gerrit-ci project, but I guess I'm limited by my time.)

(By the way, together with Bazel's reproducibility features, this is showing amazing results for how me and my colleagues roll containers for production - they're fully reproducible.)

Yes, I already looked into that a bit. This would be a lot of work for which I currently lack the time as well. Also I am not sure, if we wouldn't need some "RUN"-like commands to be run during the container build, which Bazel does not support, because they do not always allow full consistency between builds. If that is the case, we should change that, but that would take even more time. :-(

 

HTH

[David Ostrovsky]

On Wednesday, March 27, 2019 at 11:25:34 AM UTC+1, lucamilanesio wrote:

On 27 Mar 2019, at 10:18, Thomas Dräbing <thomas....@gmail.com> wrote:

FYI:

There is already a proposed change to discontinue with Java 7 and debian jessie by David Ostrovsky, which is quite old by now: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/207554

It proposes to build older Gerrit versions (<= 2.13) with Java 8 with Java 7 as target, but as Luca commented on that change, we would be unable to run tests without a Java 7 runtime.

Can we re-visit the reason for using Java 7 that was discontinued on April 2015: [1]?

It is hard for us to get the OS support with this ancient Java version. And Gerrit

users have the same problem (my guess is: nobody in the wild using Java 7, but

only Java 8). The solution is: we start building Gerrit 2.13 with Java 8, done.

I changed Buck build tool chain to produce Java 8 byte code in: [2]. I don't have

access to Java 7 any more, but SSHD-tests were failing. In: [3] I bumped SSHD

to the same version (1.4), as on stable-2.14, and now all tests are green: [4].

If we adapt the CI to use Java-8 docker container for stable-2.13 we should be

able to kill Debian Jessie container.

[1] https://www.java.com/en/download/faq/java_7.xml

[2] https://gerrit-review.googlesource.com/c/gerrit/+/219454

[3] https://gerrit-review.googlesource.com/c/gerrit/+/219453

[4] http://paste.openstack.org/show/748555

[Thomas Dräbing]

Thanks David for the changes.

Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.

Also what to do about Gerrit 2.11 and 2.12. As Luca mentioned in an earlier email on this thread, at least 2.12 is still used by some.

I am currently working on creating Debian-stretch based variants of the build-slaves and will start some tests on the test instance next week to ensure all builds will continue to work.

I would suggest to move this discussion to another thread, since due to the title marking it as a CI-related topic I guess a lot of people might not read it and moving away from Java 7 should be discussed with a broader audience.

[Doug Robinson]

Folks:

On Friday, March 29, 2019 at 5:36:08 AM UTC-4, Thomas Dräbing wrote:

Thanks David for the changes.

Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.

Also what to do about Gerrit 2.11 and 2.12. As Luca mentioned in an earlier email on this thread, at least 2.12 is still used by some.

I am currently working on creating Debian-stretch based variants of the build-slaves and will start some tests on the test instance next week to ensure all builds will continue to work.

I would suggest to move this discussion to another thread, since due to the title marking it as a CI-related topic I guess a lot of people might not read it and moving away from Java 7 should be discussed with a broader audience.

We're still running Gerrit 2.13 and Java 7 as are a number of our customers (their choice - sometimes it's very difficult to change these things).

Would definitely appreciate it if we could keep Java 7 around just a bit longer.

Cheers.

Doug

 

On Fri, 29 Mar 2019 at 00:25, David Ostrovsky <david.o...@gmail.com> wrote:

On Wednesday, March 27, 2019 at 11:25:34 AM UTC+1, lucamilanesio wrote:

On 27 Mar 2019, at 10:18, Thomas Dräbing <thomas....@gmail.com> wrote:

FYI:

There is already a proposed change to discontinue with Java 7 and debian jessie by David Ostrovsky, which is quite old by now: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/207554

It proposes to build older Gerrit versions (<= 2.13) with Java 8 with Java 7 as target, but as Luca commented on that change, we would be unable to run tests without a Java 7 runtime.

Can we re-visit the reason for using Java 7 that was discontinued on April 2015: [1]?

It is hard for us to get the OS support with this ancient Java version. And Gerrit

users have the same problem (my guess is: nobody in the wild using Java 7, but

only Java 8). The solution is: we start building Gerrit 2.13 with Java 8, done.

I changed Buck build tool chain to produce Java 8 byte code in: [2]. I don't have

access to Java 7 any more, but SSHD-tests were failing. In: [3] I bumped SSHD

to the same version (1.4), as on stable-2.14, and now all tests are green: [4].

If we adapt the CI to use Java-8 docker container for stable-2.13 we should be

able to kill Debian Jessie container.

[1] https://www.java.com/en/download/faq/java_7.xml

[2] https://gerrit-review.googlesource.com/c/gerrit/+/219454

[3] https://gerrit-review.googlesource.com/c/gerrit/+/219453

[4] http://paste.openstack.org/show/748555

--
--

To unsubscribe, email repo-d...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.

[Luca Milanesio]

On 29 Mar 2019, at 20:37, 'Doug Robinson' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Folks:

On Friday, March 29, 2019 at 5:36:08 AM UTC-4, Thomas Dräbing wrote:

Thanks David for the changes.

Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.

Also what to do about Gerrit 2.11 and 2.12. As Luca mentioned in an earlier email on this thread, at least 2.12 is still used by some.

I am currently working on creating Debian-stretch based variants of the build-slaves and will start some tests on the test instance next week to ensure all builds will continue to work.

I would suggest to move this discussion to another thread, since due to the title marking it as a CI-related topic I guess a lot of people might not read it and moving away from Java 7 should be discussed with a broader audience.

We're still running Gerrit 2.13 and Java 7 as are a number of our customers (their choice - sometimes it's very difficult to change these things).

Would definitely appreciate it if we could keep Java 7 around just a bit longer.

Java 7 is gone already, not by our choice.

I believe you guys are running a fork of Gerrit anyway (see [1]) and you are free to keep supporting it.

The discussion was about the OpenSource version of Gerrit and whether we should keep on building it on Gerrit-CI, hence the prefix [Gerrit-CI] on the subject.

Hope this clarifies.

Luca.

[1] https://github.com/WANdisco/gerrit

The LIVE DATA Company

Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[Doug Robinson]

Luca:

On Friday, March 29, 2019 at 5:07:19 PM UTC-4, lucamilanesio wrote:

On 29 Mar 2019, at 20:37, 'Doug Robinson' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

On Friday, March 29, 2019 at 5:36:08 AM UTC-4, Thomas Dräbing wrote:

Thanks David for the changes.

Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.

Also what to do about Gerrit 2.11 and 2.12. As Luca mentioned in an earlier email on this thread, at least 2.12 is still used by some.

I am currently working on creating Debian-stretch based variants of the build-slaves and will start some tests on the test instance next week to ensure all builds will continue to work.

I would suggest to move this discussion to another thread, since due to the title marking it as a CI-related topic I guess a lot of people might not read it and moving away from Java 7 should be discussed with a broader audience.

We're still running Gerrit 2.13 and Java 7 as are a number of our customers (their choice - sometimes it's very difficult to change these things).

Would definitely appreciate it if we could keep Java 7 around just a bit longer.

Java 7 is gone already, not by our choice.

But there are many in the world still running it - and not by our choice either.

 

I believe you guys are running a fork of Gerrit anyway (see [1]) and you are free to keep supporting it.

I agree.  However our "fork" is sufficiently similar at the moment that most of the plugins that our customers are using are coming from the open source community.

 

The discussion was about the OpenSource version of Gerrit and whether we should keep on building it on Gerrit-CI, hence the prefix [Gerrit-CI] on the subject.

Hmmm.

Cheers.

Doug

 

To unsubscribe, email rep...@googlegroups.com

[Clark Boylan]

On Fri, Mar 29, 2019 at 2:36 AM Thomas Dräbing
<thomas....@gmail.com> wrote:
>
> Thanks David for the changes.
>
> Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.

I can confirm that OpenStack's Gerrit is running on Java 8 (and has
been since before the 2.13 upgrade as we were under the impression
that Gerrit 2.13 required Java 8). We also do intend on eventually
(hopefully sooner than later) upgrading to 2.14/2.15/2.16, but are in
the process of updating our deployment tooling and figured getting
that sorted out first would make future Gerrit upgrades easier. It
would be nice if we can keep Java 8 + 2.13 around. We can possibly
help run some CI for that as well since we have a fairly large CI
system that knows how to talk to Gerrit (though upstream Gerrit
doesn't use the ssh stream events which may complicate things).

Also, is there any good documentation on what is involved to go from
pre notedb Gerrit to notedb Gerrit and beyond? Seems like when this
transition was first set up we had to step through versions, but now
we might be able to jump straight to 2.15 with an online DB
transition? Also as noted below this question may be getting off topic
for this thread. More than happy to follow up on this in another
thread.

[thomasmu...@yahoo.com]

@Clakr Boylan yup, you should start a seperate thread for that, also to answer it, the WMF successfully migrated to NoteDB by doing https://github.com/wikimedia/puppet/commit/06c8e4122c37508045d84840ac1cb23f4f7d9011#diff-4c58f684fb8a36946bc7616d35570c00 .

@Dave Borowitz kindkly implemented a way to do it if you use puppet as we do.

Once the migration is complete it creates a file called notedb.config (which you then move the config into gerrit.config replacing the migration config).

Also see https://gerrit-review.googlesource.com/Documentation/note-db.html#migration

[Adam Spiers]

Luca Milanesio <luca.mi...@gmail.com> wrote:
>>On 27 Mar 2019, at 15:46, Luca Milanesio <Luca.Mi...@gmail.com> wrote:

>>>On 27 Mar 2019, at 15:44, Thomas Dräbing <thomas....@gmail.com <mailto:thomas....@gmail.com>> wrote:
>>>
>>>I suggested that some time ago, when reviewing this change: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730 <https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730> .

>>>The question just is, whether the openjdk 7 from the experimental repository is stable enough to be used by the CI.
>>
>>Agreed. Best to just "tag" the current images for now than risking to have an unstable Java 7 build.
>>
>>>
>>>Since we still have a year until jessy loses its LTS-status, I would rather try to use this year to try to move everybody to a newer Gerrit version, if possible.
>>
>>That would be ideal, Java 7 is largely deprecated and unsupported.
>
>$ curl https://review.openstack.org/config/server/version
>)]}'
>"2.13.12-11-g1707fec"
>
>Are the OpenStack guys happy to upgrade their Gerrit setup or move to GerritHub?
>
>If we drop support for Gerrit v2.13, they'll lose any support from
>the community for their setup.

I can't "officially" represent the views of the folks in charge of the
OpenStack infrastructure. However I've spoken to them several times
about Gerrit and to the best of my knowledge there is every intention
to upgrade - I think it has been blocked by a lack of time, or (IIRC)
perhaps by some difficulties encountered when testing the migration,
or maybe a combination of both.

I'll dare to cross-post this sub-thread to openstack-discuss, although
I might be risking the wrath of the mailing list gods by doing so, so
please don't take for granted that the cross-posting will work
correctly :-) I can also highly recommend joining #openstack-infra on
Freenode IRC and chatting with the very helpful and friendly folks
there.

>OpenStack is a pretty big OpenSource project

Yes, IIRC it's top 3 in terms of commit velocity these days, and
possibly higher than the Linux kernel.

>not supporting them anymore would be a problem I believe.

Good to hear - thanks a lot for thinking of us ;-)

[David Ostrovsky]

On Sunday, March 31, 2019 at 3:30:34 AM UTC+2, Clark Boylan wrote:

On Fri, Mar 29, 2019 at 2:36 AM Thomas Dräbing
<thomas....@gmail.com> wrote:
>
> Thanks David for the changes.
>
> Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.

I can confirm that OpenStack's Gerrit is running on Java 8 (and has
been since before the 2.13 upgrade as we were under the impression
that Gerrit 2.13 required Java 8). 

 

Thanks for confirming. I just checked with LibreOffice infra team

and they are also running Gerrit 2.13.13 on Java 8. So I think we

can discontinue community support for 2.13 release on Java 7.

[Luca Milanesio]

+1 that sounds good.

Luca.

[Thomas Dräbing]

+1

Do we have some kind of mirror for build artifacts from the CI, other than the CI itself? It might be helpful for some people to at least still have access to the current artifacts for a while (especially plugins). Especially, if we decide to remove jobs building Gerrit stable-2.10 - stable-2.12, since we can't switch to Java 8 for them.

[luca.mi...@gmail.com]

Sent from my iPhone

On 2 Apr 2019, at 08:10, Thomas Dräbing <thomas....@gmail.com> wrote:

+1

Do we have some kind of mirror for build artifacts from the CI, other than the CI itself? It might be helpful for some people to at least still have access to the current artifacts for a while (especially plugins).

But if people have access to them, they’ll use it and we all have to support them. Without even a working build, how can we support them at all?

Especially, if we decide to remove jobs building Gerrit stable-2.10 - stable-2.12, since we can't switch to Java 8 for them.

My understanding is that we drop

java 7 and all aupport for anything older than Gerrit 2.13, isn’t it?

[Thomas Dräbing]

On Tue, 2 Apr 2019 at 09:42, <luca.mi...@gmail.com> wrote:

Sent from my iPhone

On 2 Apr 2019, at 08:10, Thomas Dräbing <thomas....@gmail.com> wrote:

+1

Do we have some kind of mirror for build artifacts from the CI, other than the CI itself? It might be helpful for some people to at least still have access to the current artifacts for a while (especially plugins).

But if people have access to them, they’ll use it and we all have to support them. Without even a working build, how can we support them at all?

Good point. My point was more to have a kind of archive of artifacts that are expressly not supported anymore. But we should definitely not encourage people to stay on these versions. I am fine with not having one, just wanted to put the thought out here.

Especially, if we decide to remove jobs building Gerrit stable-2.10 - stable-2.12, since we can't switch to Java 8 for them.

My understanding is that we drop

java 7 and all aupport for anything older than Gerrit 2.13, isn’t it?

Yes, that's I think the idea. 

[Luca Milanesio]

On 2 Apr 2019, at 08:59, Thomas Dräbing <thomas....@gmail.com> wrote:

On Tue, 2 Apr 2019 at 09:42, <luca.mi...@gmail.com> wrote:

Sent from my iPhone

On 2 Apr 2019, at 08:10, Thomas Dräbing <thomas....@gmail.com> wrote:

+1

Do we have some kind of mirror for build artifacts from the CI, other than the CI itself? It might be helpful for some people to at least still have access to the current artifacts for a while (especially plugins).

But if people have access to them, they’ll use it and we all have to support them. Without even a working build, how can we support them at all?

Good point. My point was more to have a kind of archive of artifacts that are expressly not supported anymore. But we should definitely not encourage people to stay on these versions. I am fine with not having one, just wanted to put the thought out here.

We made clear already in the past that Gerrit-CI was not a repository of artifacts. As a matter of fact, old builds are evicted and removed already right now. If you have downloaded and installed something previously, it isn't available anymore right now.

We can think about publishing to Maven or Google Cloud for those that are owned and managed by Gerrit contributors.

What do you think?

Especially, if we decide to remove jobs building Gerrit stable-2.10 - stable-2.12, since we can't switch to Java 8 for them.

My understanding is that we drop

java 7 and all aupport for anything older than Gerrit 2.13, isn’t it?

Yes, that's I think the idea. 

+1

[Thomas Dräbing]

Some kind of artifact repository would certainly be useful. I remember a recent mailing list thread, where a newer plugin version was not compatible anymore with a previous patch version of Gerrit 2.16 and when I looked on the CI a compatible plugin version was not available anymore.

But we digress. That would be a different project to tackle.

[Luca Milanesio]

On 2 Apr 2019, at 09:50, Thomas Dräbing <thomas....@gmail.com> wrote:

Some kind of artifact repository would certainly be useful. I remember a recent mailing list thread, where a newer plugin version was not compatible anymore with a previous patch version of Gerrit 2.16 and when I looked on the CI a compatible plugin version was not available anymore.

True, however it would require a significant effort and storage the build and support of all plugins of all versions.

Not sure either if we can legitimately use the com.google.gerrit organisation on Maven for that.

But we digress. That would be a different project to tackle.

Yep.