* Max Rydahl Andersen <manderse@xxxxxxxxxx> [2014-11-18 07:11]: > >>>1. Fedora can not legally redistribute Oracle JDK. > >> > >>I know - hence why I would think having a openjdk 7 build would make > >>sense. > >> > > > >Oracle JDK7 and OpenJDK 7 will both EOL in April 2015: > >http://www.oracle.com/technetwork/java/eol-135779.html > > > >So they will expire within the lifetime of Fedora 20 and 21, and it > >again comes down to volunteer for maintainership at that point. > > My point is that Oracle JDK 7 is just one of many many packages you have > that actually declare when they will EOL. > > Other packages just stops being maintained, but still are included since it > was not known the support/maintanence would stop. > > Just seems like it would be good if there was a way to have these packages > made available despite it is known it will stop being maintained. > > >>>2. Fedora can not distribute something that Fedora developers can not > >>>support if there is a problem in it (as it is with Oracle JDK). > >> > >>so *any* package that is known to be marked as EOL sometime in the > >>future > >>before the upcoming Fedora EOL's gets removed from that future Fedora > >>release ? Even that Java 7 is still the most used and targeted Java > >>version > >>? > >That is not the case. OpenJDK7 will EOL before 20 and 21, and despite > >that, we will support it in 20. OpenJDK7 has been removed only from > >Fedora 21. > > I asked if any package gets removed and you say openjdk7 will be removed. > How about other packages ? just wondering if the jdk package is treated > specially > because there is a public EOL date on it? > It is a combination of EOL date and effort required for maintenance. Our work in Fedora is not just limited to security backports, but also to bug fixes and significant testing. Each release is TCK tested to ensure that it meets the spec. While our team cannot take on this additional load as it is not priority, if someone from the community wants to step up and take responsibility for maintaining an older version as a secondary JDK, we have no issues with that. > >>How does fedora handle it when a package stops being maintained > >>midstream > >>with not proper warning ? Do they get removed or just lets getting be > >>stale > >>? > >> > >>If removed - why couldn't that be done for Java7 ? > >> > >>If just letting get stale - why couldn't that be done for Java7 ? > > > >Security is the biggest reason for not doing this. Java has CPUs each > >quarter at the least, so within 3 months we would end up with a version > >with major security issues. > > which is why I suggested having these made available separately somehow. > Separately how? As a secondary non-default JDK you mean, or a separate 3rd party repo like copr? > >>And I assume the answers is you just don't have time/power to maintain > >>it > >>and thats is fully grokkable - but then > >>it seems to me it would be good for users if we at least explain how > >>they > >>can use another Java 7 in fedora eclipse context (which was the initial > >>question here) > >> > > > >We shouldn't recommend users to use an unsupported, insecure version. I > >understand that that is not the case right now, but it will be within > >a few months of F21 being released. > > > >The appropriate solution IMO is that users file bugs for 8 and we fix > >them so that everyone can benefit. > > Can't really fix issues with other projects code that are dependent on Java > 7 because of changes > in Java 7 by fixing Java 8 :) > I understand. As I said above, if someone is willing to accept the responsibility for doing timely security backports and maintenance, they are welcome to do so :) Deepak > /max > http://about.me/maxandersen -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
