If the mass rebuild, after the change application, breaks to much packages, or some important will be unfixable, jdk8 must be restored back to the position of system jdk.
Contingency mechanism: Return jdk8 as system jdk and mass rebuild again. Note, that this may be very hard, because during build of packages by jdk8, by jdk11 built dependencies will be picekd up, so build will fail. Maybe several iterations of mass rebuild will be needed.

As said on the mailing list, changes like this should be done and tested in a side tag. I have even offered help with that, but this was not changed in the proposal.

Oh i'm sorry for misunderstanding. I will do that in side tag, and I mentioned it in the proposal. I thought it as enough.

+1

+1

Oh i'm sorry for misunderstanding. I will do that in side tag, and I mentioned it in the proposal.

I am sorry but I cannot find this information in the proposal.

In https://fedoraproject.org/wiki/Changes/Java11#Contingency_Plan
* possible solution
* https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag

possible solution != this is what we are going to do

ok. rephrased.

I'm +0.

is +0 opposite of -0? Aka better to do that then not, but officially I'm not voting?-)

Is this agreed then? If so, I will proceed to adjusting the provides and sidetagging.

No, it is not agreed yet.

I agree with the general intent of this change, but the way the change proposal is presented seems very confusing, I still have no idea how the rebuilds will be managed, when, what is the minimal set of packages that need to succeed before the contingency plan is activated, who does what. E.g. the "scope" section is very vague and is says the change owners will:

• based on above, adapt jdk8 and jdk11 package provides
• If necessary tune the build environment

And other developers might adapt their packages. Who does the rebuilds in the side tag? is it releng? Is it @jvanek. Is it me?

Thank you for the concerns, those help to clarify a lot.

I hope I will do the single mass rebuild in side tag, if necessary with yours help, or anybody else in what remained from javasig.

There is probably still lag of my sidetag expereince. Can I start mass rebuild here once jdks are ready in side tag? Or can I just ping you/releng ticket once the jdks are ready in sidetag?

Can I start mass rebuild here once jdks are ready in side tag?

Yes, in that side tag. Feel free to ping me or even schedule a call in the work calendar, I can walk you trough it.

Could you edit the scope to make it more clear? I suggest not just adding more stuff, but actually change the scope to describe the procedure?

Something like:

Change owners:

• will create a dedicated side tag
• will build the adapted jdk8 and jdk11 packages in it
• will mass rebuild all the affected packages in it
• will contact maintainers trough bugzilla if something is broken and provide help and guidance
• will determine when/if the side tag is merged based on the general success / failure rate and the following critical packages functionality: libreoffice, maven, ant, eclipse (I have just made the list up)

Other developers:

• will fix their packages if broken
• will retire their packages if beyond fixing and not dependend upon
• will hardcode the dependency on Java 8 if needed and applicable

Thanx. Will rework it as you suggest

After a week, I count the vote as (+2, 1, -0). Tagging this for the next meeting. The change owner has made significant edits to incorporate feedback from this issue.

+1

+1

+1 for the change

On the topic of sidetags:

I wonder if it makes sense to use not just a custom sidetag, but the multi-package update functionality (see https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ ). This way, you won't need to test a mass-rebuild on the side first and then repeat it later after the change is merged into Rawhide, but you can land the entire sidetag in Rawhide as one big Bodhi update.

This way, you won't need to test a mass-rebuild on the side first and then repeat it later after the change is merged into Rawhide,

This is not how custom side tags work. The side tags builds are landed in rawhide (or not, when not desired).

@churchyard Thanks for clarification

APPROVED (+8, 1, -0) on the meeting https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-20/fesco.2020-04-20-15.00.html

Hi!

From my point of view, the change is ok to go, And the sidetag will be ok tomerge in week or two.
There is rised blocker to the change: https://pagure.io/fesco/issue/2449
there is one additional idea to the proposal: https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-50266 but that is unlikely to happen in time.

rcm side tag ticket: https://pagure.io/releng/issue/9574

@jvanek I keep telling you, waiting another "week or two" to merge the side tag is a big no-no since it collides with the planned F33 mass rebuild this week.

Either the side tag needs to be merged before the mass rebuild is started (within the next 1-2 days) or the default needs to be reverted to Java 8 for the mass rebuild, switched to 11 again after it's done, and do another Java 11 mass rebuild. I see no other options right now.

dec

@decathorpe Is it now already? Forking is 11th august, Is forking so much earlier?.... I see... 22nd of july.. Ok.