> I have added it to the list of alternatives the Planning Council will discuss > next Wednesday,
Thanks for adding this to the agenda. > I think simply applying the patches (without the normal development cycle of > community feedback, > and testing) sounds a bit dangerous for something intended to "show off" how > great we are The idea behind this proposal is to take bits previously officially released and combine them in the way that an end user would combine them. So, if a project is comfortable with their patch that Mike is getting ready to promote more broadly, there is no reason to differentiate applying the patch by the user vs applying the patch by an automated process. The end result is binary identical. The same could not be said about my initial Kepler SR3 proposal which would require re-building from source per our usual release process. That approach is arguably cleaner, but would require more testing to at least ensure that nothing unintended has slipped into the build. Several JDT devs on this thread have voiced concern over stability of Java 8 support since it hasn’t had time to shake out all the bugs. In light of those concerns, perhaps it would be appropriate to label the patch repositories and the proposed packages as “Java 8 Support Tech Preview”. I think everyone would agree that making a tech preview available in more forms to make it easier for users to consume benefits everybody. And before anyone brings that up again, no, that’s not the same thing as using a Luna I-Build. In this thread I have heard the following used as justification for why action is not necessary: 1. Users would not mind waiting three months for Luna GA. 2. Users would not mind using a Luna I-Build or Luna M7 (after waiting until May for it). 3. Users would not mind applying patches to Kepler SR2 on their own. 4. The patches aren’t ready for prime time. 5. It’s a lot of work to add this unplanned release. One of my justifications for making this offer is that I’d like to take “a lot of work” argument off the table by offering to do basically all of the work myself. I would need help getting the new packages on the download server and updating the download pages, but that’s it. So if the Planning Council votes to maintain status quo, I do not want to see “a lot of work” used in the justification. J - Konstantin From: [email protected] [mailto:[email protected]] On Behalf Of David M Williams Sent: Thursday, March 27, 2014 10:05 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Konstantin, thanks for the offer. I have added it to the list of alternatives the Planning Council will discuss next Wednesday, but off the top of my head, I think simply applying the patches (without the normal development cycle of community feedback, and testing) sounds a bit dangerous for something intended to "show off" how great we are. But, I'll see what rest of Planning Council thinks. Thanks again. (And, if not that, I'm sure there's plenty of other ways you can help). = = = = All, I have opened a bug to get a concrete list of "who has something for Java 8 to patch Kepler SR2". I know some of you have mentioned it here on this list, but it is easy for me to miss something, so please repeat. Please see/respond in bug 431427. <https://bugs.eclipse.org/bugs/show_bug.cgi?id=431427> Bug 431427 - Who has "Java 8 Patch" for Kepler SR2? Please give the data requested there by next Tuesday, April 1 (no, no fooling) so that the Planning Council has the data available when they meet on Wednesday, April 2. (but, no need to argue, there in the bug, pros and cons of various plans ... I think we have done that here on this list, and my hope is the Planning Council can come to some consensus on the best course of action). I also wanted to give my sincere apologies for not thinking to coordinate or plan this better. It seems the Java 8 support patch caught many people by surprise. While there has been occasional "status updates" and mentions of it announced on "eclipse-dev" list (and else where), I think that 1) that doesn't get the visibility we thought it did, and 2) I suspect there was a certain tone of caution that leads to "under promise and over deliver" -- after all, it was a pretty large, risky proposition to begin with, and quite an accomplishment the JDT team (and others) were able to pull it off. But still, apologies for not thinking ahead on this one. Thanks to all of you who have commented on this issue, and care so deeply about Eclipse. From: "Konstantin Komissarchik" <[email protected]> To: "'Cross project issues'" <[email protected]>, Date: 03/27/2014 10:45 PM Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Sent by: [email protected] _____ Clearly debating this further will not lead to anything productive, so how about this instead… I will volunteer to write a script that takes existing Kepler SR2 packages, installs the Java 8 patches into them and re-packages them. I will do all the work if I have a commitment to publish these packages at a reasonable location in eclipse.org main downloads area. - Konstantin From: [email protected] [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of Doug Schaefer Sent: Thursday, March 27, 2014 4:26 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? I understand your frustration. I think your efforts would be better spent though trying to convince the community to action with hard data, like the number of users who are switching to Java 8 right now that can't figure out how to install the feature patch. Is there a bug report where this is being gathered? Doug. _____ From: <mailto:[email protected]> [email protected] [[email protected]] on behalf of Konstantin Komissarchik [[email protected]] Sent: Thursday, March 27, 2014 5:03 PM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? You seem to be saying that I don’t know how these releases are put together or who does the work. That’s low. You are quite right that there is no consensus. It is quite sad to see this. There is lots of talk about needing to make ensure that Eclipse remains competitive, but when time comes to do something concretely towards that, there is little interest. Let there be no mistake, it is a bad completive position to have Eclipse ship official Java 8 support three months behind the competition. For developers immersed in Eclipse internals daily, it may not seem like a big deal to ask users to seek out and install various patches or to use a Luna pre-release build or to just wait, but average users don’t see it that way. - Konstantin From: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of Doug Schaefer Sent: Thursday, March 27, 2014 12:35 PM To: <mailto:[email protected]> [email protected]; Cross project issues Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? Yes, you have to remember, the Foundation doesn't put together releases, the projects do. And Mike is correct, there isn't consensus from the projects that a Kepler SR3 is warranted versus putting resources on Luna. The feature patch install is easy and just needs to be made more visible, as Mike is proposing to do. Doug. _____ From: <mailto:[email protected]> [email protected] [[email protected]] on behalf of Mike Milinkovich [[email protected]] Sent: Thursday, March 27, 2014 1:43 PM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? On 27/03/2014 1:28 PM, Konstantin Komissarchik wrote: Well, it is more work, but it shouldn’t be a lot of work since the bulk of it is automated and I would think that the value to Eclipse community and Eclipse reputation would outweigh the investment. My impression is that there is no consensus that a Kepler SR3 is desirable. That is part of the reason why we're proposing the steps outlined in my email from earlier today. In any event, I think that posting on this thread was a mistake. I've started a new thread and will hopefully get some feedback on what the EF is proposing to do. -- Mike Milinkovich [email protected] +1.613.220.3223_______________________________________________ cross-project-issues-dev mailing list [email protected] <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
