To be really honest, I still don't like this. To me, it felt like a foregone conclusion since the first part of this proposal was filed, especially since suggestions for other approaches to lower maintenance burden were not seriously considered. Hence I remain -1 on this.

I'm not very happy either, but I'm a weak +1 given the constraints of the team and validation tests and all. I wish there were a better way though. ;(

It's not great, but current approach is not sustainable and we don't have any better ideas. I trust the maintainer has considered all the pluses and minuses of various approaches and that this is the most reasonable choice. (And if it turns out not to work as expected, e.g. if there are delays or more CVEs or whatever, we can always try a different approach later.)

+1

I'm still -1 on this. Fundamentally, Fedora does not support building packages this way. I know that technically it's possible to make it work, but in my opinion the proposed workflow deviates too much from standard Fedora process to be acceptable.

The other thing to consider is that this proposal is not just for a single package there are four separate jdk packages that will be using the process, not to mention the fact that I can see maintainers of other hard-to-build packages wanting to do something similar.

My recommendation for the change owners is continue to discuss with bodhi maintainers about how to add first class support for this kind of workflow in bodhi. I know that the maintainers have already said this won't be easy, but I think it's worth at least trying to get this on a roadmap or having a more detailed design discussion, because I think this feature could be very useful for Fedora.

@tstellar Please read contingency plan. Are you sure yo want fedora goes this way?

Tagging with meeting due to -1 votes.

FWIW, I'm +1 on the grounds that it's the best of a series of bad options.

This was discussed during today's FESCo meeting:
AGREED: We will continue voting in the ticket, with the tally reset

Still +1 from me.

My vote also still remains at -1.

It doesn't help that I actually like the "Plan B" listed under Contingency Plan better than the Change Proposal itself ...

Still +1 here. It seems least bad, but I agree the contingency doesn't seem all that unreasonable...

Still -1.

@tstellar makes a valid point regarding the departure from how Fedora builds packages. There is a risk of other packages wanting an exception like this down the road, so assuming that will happen we should have our build infrastructure support it in a more official capacity. On the other hand, I understand the risk of not approving this and putting the JDK maintainers in a difficult position. What would be nice is if we can approve this now but make sure there is a change proposal covering extending Bodhi (and other tools) for this functionality.

@dcantrel Right. I may try to pursue https://github.com/fedora-infra/bodhi/issues/5387 but according to latest comments its not going to be easy, and I lack most of the needed expertise.

As for other packages getting this exception, it should not be easy:
- jdk requires certification
- jdk have to remain system integrated as runtime
- jdk have to remian build system integrated as compielr
- jdk should be offered in several versions
- jdk is designed to be portable
- in this last bullet is necessary to highligth, that since jdk9, dynamically linked jdk is malfunctioning beyond repair

its quite hard to imagine any other package being in so dummy position.

Echoing @tstellar's concerns, I am -1 on this proposal.

Voted on in meeting:

APPROVED(+5,0,-3)

thank you!