Community
Participate
Working Groups
I have removed Oracle Solaris, HP-UX and IBM AIX from the Target Environments but not yet updated the JRE minor/update versions. Appendix "Execution Environment by Bundle" is not yet up-to-date.
(In reply to Dani Megert from comment #1) > I have removed Oracle Solaris, HP-UX and IBM AIX from the Target > Environments but not yet updated the JRE minor/update versions. > > Appendix "Execution Environment by Bundle" is not yet up-to-date. From our side - RHEL 6 can be dropped as we don't plan any test/support for it for Oxygen.
(In reply to Alexander Kurtakov from comment #2) > From our side - RHEL 6 can be dropped as we don't plan any test/support for > it for Oxygen. Alex, this is what you said in our July 5 PMC meeting (https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes): Alex: Initial builds of GTK 2.24 for AIX - planning to bump minimum GTK version to 2.24 - RHEL 6: 2.24.23-6 Is this obsolete? We should discuss support for RHEL 6 in our next meeting.
(In reply to Dani Megert from comment #3) > (In reply to Alexander Kurtakov from comment #2) > > From our side - RHEL 6 can be dropped as we don't plan any test/support for > > it for Oxygen. > > Alex, this is what you said in our July 5 PMC meeting > (https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes): > > Alex: Initial builds of GTK 2.24 for AIX - planning to bump minimum GTK > version to 2.24 > - RHEL 6: 2.24.23-6 > > Is this obsolete? We should discuss support for RHEL 6 in our next meeting. Both are true. I'm not interested in removing RHEL 6 support (yet) but I'm interested in having RHEL 6 removed from the target environments list to give a year notice that RHEL 6 (and GTK 2 as result) is no longer amongst the primary/well tested platforms. Aka downgrade RHEL 6 support to any other Linux distro.
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_7_draft.xml As you can see, the biggest change is that I replaced the static top-level items with the concrete sub-project plans. I also didn't split them up into themes. I'm still working on getting rid of the Themes and Priorities section, but that seems to be hard-coded into the plan format. I'm talking to Wayne regarding this. The echo so far (in last PMC call) was positive. I've opened bug 499102 to track whether there is an easy way to automatically inline the sub-project pages into our main plan. I would also like to remove the 'proposed', 'committed' and 'deferred' status/section/wording. The status can be seen live on the plan bugs. And in the past we always started with only proposed items and then moved them to 'committed' when they were done, or deferred some.
(In reply to Dani Megert from comment #5) > https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_7_draft.xml > > > I'm still working on getting rid of the Themes and Priorities > section, but that seems to be hard-coded into the plan format. I'm talking > to Wayne regarding this. From Wayne: "I haven't looked at that implementation in years. I'm pretty sure that the answer is no."
(In reply to Alexander Kurtakov from comment #4) > (In reply to Dani Megert from comment #3) ... > > Alex: Initial builds of GTK 2.24 for AIX - planning to bump minimum GTK > > version to 2.24 > > - RHEL 6: 2.24.23-6 > > > > Is this obsolete? We should discuss support for RHEL 6 in our next meeting. > > Both are true. I'm not interested in removing RHEL 6 support (yet) but I'm > interested in having RHEL 6 removed from the target environments list to > give a year notice that RHEL 6 (and GTK 2 as result) is no longer amongst > the primary/well tested platforms. Aka downgrade RHEL 6 support to any other > Linux distro. Ah, Linux. In principle I guess this is fine, although it does seem odd that we're supporting the version of GTK that comes with the distro, but not the distro.
There doesn't seem to be a lot of consistency between the subproject plans. The font sizes seem to be somewhat random, and some of them list bugs for the individual items and some do not. Is this worth getting them to fix? It would make it easier on the reader, at least.
(In reply to McQ Wilson from comment #8) > There doesn't seem to be a lot of consistency between the subproject plans. > The font sizes seem to be somewhat random, and some of them list bugs for > the individual items and some do not. Is this worth getting them to fix? It > would make it easier on the reader, at least. Which on did you like most, so we can use it as the template for the others?
(In reply to Dani Megert from comment #9) > > Which on did you like most, so we can use it as the template for the others? > I'm not sure how much my vote counts for style. :-) I was just looking for consistency. I thought the Platform UI one was reasonable, for example.
(In reply to McQ Wilson from comment #7) > (In reply to Alexander Kurtakov from comment #4) > > (In reply to Dani Megert from comment #3) > ... > > > Alex: Initial builds of GTK 2.24 for AIX - planning to bump minimum GTK > > > version to 2.24 > > > - RHEL 6: 2.24.23-6 > > > > > > Is this obsolete? We should discuss support for RHEL 6 in our next meeting. > > > > Both are true. I'm not interested in removing RHEL 6 support (yet) but I'm > > interested in having RHEL 6 removed from the target environments list to > > give a year notice that RHEL 6 (and GTK 2 as result) is no longer amongst > > the primary/well tested platforms. Aka downgrade RHEL 6 support to any other > > Linux distro. > > Ah, Linux. In principle I guess this is fine, although it does seem odd that > we're supporting the version of GTK that comes with the distro, but not the > distro. This is not the intent. The intent is to state that while Oxygen will work on RHEL 6 (like on e.g. Debian, Mageia, etc. - we don't list distros that should work explicitly) it is no longer one of the primary tested environments aka "target environments".
(In reply to McQ Wilson from comment #10) > (In reply to Dani Megert from comment #9) > > > > Which on did you like most, so we can use it as the template for the others? > > > I'm not sure how much my vote counts for style. :-) I was just looking for > consistency. I thought the Platform UI one was reasonable, for example. +1. Platform UI is doing this planning since a few releases and we usually spend some time on it.
I suggest to remove Ubuntu 14.04 also as target platform. This should simplify testing for the Linux side. I think we can expect users who want to use the latest Eclipse release to move to the 16.04 release.
(In reply to Lars Vogel from comment #13) > I suggest to remove Ubuntu 14.04 also as target platform. This should > simplify testing for the Linux side. > > I think we can expect users who want to use the latest Eclipse release to > move to the 16.04 release. Makes sense to me - declaring fewer LTS versions as target environments should help improving experience on them.
The plans have been unified.
(In reply to Alexander Kurtakov from comment #4) > ... I'm not interested in removing RHEL 6 support (yet) but I'm > interested in having RHEL 6 removed from the target environments list to > give a year notice that RHEL 6 (and GTK 2 as result) is no longer amongst > the primary/well tested platforms... > In this context, which is to say that we expect RHEL 6 to still work in 4.7, but will remove support in 4.8, I vote +1.
(In reply to Lars Vogel from comment #13) > I suggest to remove Ubuntu 14.04 also as target platform. This should > simplify testing for the Linux side. > What would be the material benefit of dropping 14.04? Is this because of GTK incompatibility as well? > I think we can expect users who want to use the latest Eclipse release to > move to the 16.04 release. > The real question is, can we expect users of *products* built on Eclipse that were targeted at a long term support version of the operating system to be willing to switch? The Release date for 14.04 LTS was only two years ago.
(In reply to Dani Megert from comment #15) > The plans have been unified. > Thanks. +1 for the plan in general, once we close on the supported platforms.
(In reply to McQ Wilson from comment #16) > In this context, which is to say that we expect RHEL 6 to still work in 4.7, > but will remove support in 4.8, I vote +1. Exactly my intention. Have a two step removal process - declare it's no longer our primary target this year. Dropping support next one. (In reply to McQ Wilson from comment #17) > What would be the material benefit of dropping 14.04? Is this because of GTK > incompatibility as well? For me this is more of setting proper user expectataions. There are quite a number of fixes and enhancements in newer GTK versions - biggest change being significantly improved CSS engine in GTK itself and SWT detecting at runtime if running on GTK 3.14+(even better with 3.16+) (Ubuntu 14.04 has GTK 3.10) and making use of this improved css engine to initialize color constants from css theme, set/getBackground through it, proper overlay scrollbars and scrolling when scrollbars invisible, better default sizing and styling through initial css load on Device init and etc. All of that not possible or not enabled for older GTK versions due to problems. In short - 14.04 will work (and do so at least for the next 2 years releases) but sent the message clear that our target environment is newer GTK versions where users can get way better experience thanks to both GTK improvements and SWT making use of these improvements. > > > I think we can expect users who want to use the latest Eclipse release to > > move to the 16.04 release. > > > The real question is, can we expect users of *products* built on Eclipse > that were targeted at a long term support version of the operating system to > be willing to switch? The Release date for 14.04 LTS was only two years ago. We do not expect these users to switch as there software will continue to work in the way it does today (and this is what they should expect) but we tell them that we put the limited resources available into making SWT not fall behind the rest of the desktop environments and put the majority on our effort into improving newer GTK versions. Message I want to get out is - things work as they used to on old versions(minus ancient versions e.g. 2.18 to 2.24 min requirement for this year) but when it comes to new additions and general improvements the target are newer versions and if you want to see/use them you have to move on. +1 on the plan from me.
(In reply to Alexander Kurtakov from comment #19) +1 for Alex explanation to Ubuntu 14.04 > +1 on the plan from me. +1 for the plan also from me
The PMC agreed to the plan in its August 16 meeting. The Ubuntu case was not decided and will be discussed for the next plan update (bug 499768).
