----- Original Message ----- > From: "Mario Torre" <neugens@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Thursday, February 26, 2015 4:59:35 PM > Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora > > On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote: > > On 02/24/2015 05:21 PM, Mario Torre wrote: > > > On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote: > > >> On 02/24/2015 02:15 PM, Jiri Vanek wrote: > > >>> On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote: > > >>>> I am against official guidelines or policy for legacy JDK packages. I > > >>>> don't think that any such policy is needed and it would only encourage > > >>>> adoption of old packages for which there might be no security updates. > > >>> > > >>> Well thats the point - people are calling for them. And wont to > > >>> maintain > > >>> them with this risk. > > >> > > >> I thought that the point of this change proposal was "enabling community > > >> to maintain legacy JDKs", not encouraging people to package them without > > >> good reason or without involvement to truly maintaining them. Packaging > > >> older JDKs is *already* possible, so IMHO this change accomplishes > > >> nothing but showing people how they can dump old, unmaintained software > > >> into Fedora. > > > > > > Well, in this case it would not be un-maintained, the Fedora package > > > would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we > > > are still actively contributing to the upstream software in its various > > > versions. While you as a packager cannot specifically count on that, > > > there's still a level of confidence that the base software won't be > > > abandoned any time soon. And even when we will stop supporting those > > > older versions, the community will take over if there is a need for > > > that, exactly like we have done ourselves before. > > > > > > Indeed, there's an overhead for the downstream maintainers, we may need > > > to drop specific version of OpenJDK, or skip a release, or do other > > > funny things and the Fedora maintainers will have to adapt, but this is > > > no different than usual I believe. Realistically, we are so conservative > > > with older JDKs that I doubt this will ever really be an issue. > > > > Correct me if I am wrong, but in my understanding maintaining JDK > > package requires a lot of ongoing work (including obtaining and applying > > patches, running TCK, pushing updates in timely manner and so on). JDK > > maintainers should know this and I'm assuming that the amount of > > required work is the main reason for them not wanting to maintain older > > JDKs. > > > > The work required to add old JDK package to Fedora is relatively small > > compared to ongoing maintenance work. Someone willing to truly maintain > > JDK in Fedora should have knowledge about JDK packaging and they > > shouldn't have problem finding time to come up with a working solution, > > proposing and discussing it. > > Indeed, but don't underestimate this "relatively", which is the main > reason why *we* won't do that. > > > If you make the process of adding legacy JDKs to Fedora too easy then > > someone without enough time and required knowledge will surely do that > > and we may easily end with unmaintained package. I'd rather not have old > > JDK than have unmaintained JDK with security holes. > > I don't see how giving proper rules means making something like that > "easy". The fact is that making things artificially complicated just to > scare off people from doing them doesn't really match with my view of > Freedom. I think instead that rules, however complex for the matter at > hand, should be crafted so that they impose the minimum possible > overhead. > > In this case, it's about giving users one thing they asked, which is > easy access to a previous version of Java. We can't afford maintaining > it as Java Team, but this doesn't mean we will refuse to help people > doing it. In fact, the exact existence of this very same discussion is > our attempt to pass the ball back to the Community. > > > >> Package that doesn't pass review shouldn't be part of Fedora. > > > > > > Well, if your goal is to reduce the user base of Fedora, I'm sure we can > > > talk about removing the JDK :) > > > > We can't sacrifice our basic principles (such as passing review) for the > > sake of increasing user base. > > If you put the mean before the end, yes. But I hope you will agree with > me that one of those core principles *is* the Freedom of allowing users > to use such a critical tool as Java for their own daily reasons > *without* forcing them to switch distribution. > > While I see your point that this can be extended to anything (why don't > we package an older Eclipse?) so we need to draw a line, I believe an > important core component like the JDK falls in that category of things > that should be allowed to coexist even a bit longer than originally > intended. > > Now, the question is how to make this happens by preserving both quality > and freedom. Adding exceptions for selected packages is definitively not the way to go. I would agree with everyone that tries to make Fedora more open in general. Name yours or all of: * Every packager can sponsor others (thus no sponsor level needed) * Every packager can commit to every package (thus no proven packager needed) * Name yours. But adding exceptions per package whenever someone comes with a usecase is not improving the way the distribution works it just makes it more complicated by adding more and more rules/guidelines/exceptions/etc. so we end up with not a single person knowing what/when/where is allowed. If somebody tries to open Fedora more and kill bureaucracy I would support him/her thousands of times, but I'll object adding exceptions to the overly complicated bureaucracy we already have. Hope that simplifies why the resistance. Alexander Kurtakov Red Hat Eclipse team > > Cheers, > Mario > > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
