No, a tab is fine (at least for me), but as said, let's discuss the 
implementation in the bug.

Dani



From:   Doug Schaefer <dschae...@qnx.com>
To:     Cross project issues <cross-project-issues-dev@eclipse.org>
Date:   04.04.2014 16:26
Subject:        Re: [cross-project-issues-dev] Kepler SR2 with Patches 
pre-installed
Sent by:        cross-project-issues-dev-boun...@eclipse.org



I think David's main point and I think there was agreement on was that 
these downloads need to look very different from official releases. That 
rules out a tab (which isn't very prominent anyway) and a link in the mix 
with the other downloads (which is too prominent). I mentioned putting 
something in the right panel, not necessarily in the Related Links section 
but maybe in it's own section above the Related Links. I think that's a 
nice compromise. 

Doug.


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Konstantin 
Komissarchik [konstantin.komissarc...@oracle.com]
Sent: Friday, April 04, 2014 10:19 AM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Kepler SR2 with Patches 
pre-installed

David,
 
As long as we are clarifying things? The Planning Council did decide to 
label it as ?Kepler SR2 with Java 8 patches applied?, but I heard no 
resolution to the question of how it should be presented on the downloads 
page. Several options were discussed, including a tab (my personal 
preference that I labeled as such in this e-mail) or a banner similar to a 
promoted download, but no conclusion was made. In particular, the Planning 
Council did not resolve to expose this through a link in small font under 
?Related Links? as you propose in the notes. In fact, I made it clear 
several times that my offer to produce these packages is conditioned on 
the result being prominently displayed on the downloads page and not 
hidden where people have a hard time finding it. 
 
I do not see anywhere in my e-mail that I have misrepresented what the 
Planning Council has decided and deeply resent the implication.
 
- Konstantin
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Friday, April 04, 2014 12:02 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Kepler SR2 with Patches 
pre-installed
 
I wanted to correct the title of this note and thread, since it was clear, 
that the planning council in no way considers this "SR3" and one of our 
cautions was not to "oversell it". 
It is after all, making something available for mass downloads, that has 
not had any quality control at all. In theory it should work just fine ... 
but no quality engineer would ever accept "in theory" as adequate quality 
control. While the probability of surprises is low, the consequences of 
surprises is high -- we'd could end up giving a bad impression in the 
community and industry -- the opposite of that we are trying to do. (And 
as everyone knows, "satisfaction" is highly related to what ones 
pre-conceived expectations are). 

Similar, the recommendation of "stable", Java 8, Luna 6 as the tabs is 
opposite, from what Planning Council recommended. In no way, should SR2 + 
Patches be presented as "above" the Official Service  Release -- it is no 
release at all -- it is simply "Kepler SR2 with patches pre-applied" 
(which is the wording the planning council recommended), as well as 
placing the links on the existing "Java 8" page that the EF has kindly 
provided. And I have already communicated all this to the, EF (Wayne) as 
we agreed in the meeting.   

We really appreciate Konstantin doing this work, but felt I had to speak 
up and clarify on several items, he is giving his view, not the view of 
the Planning Council. 

Luckily, the Eclipse Foundation "owns" those pages, and as always, they 
can decide themselves how to balance risk with "marketing". 

And to clarity one more thing ... I will not argue further about this on 
this list ... so will not respond again to this topic on this list, as in 
my experience that would be counter productive if not disruptive.  So if 
the conversation continues, my silence does not imply agreement ... nor 
that I do not care -- I care deeply. I am responding this once trying to 
correct any mis-representations of "what the Planning Council said". And, 
beside, the purpose of this list is to communicate about the Simultaneous 
Release, not to argue or editorialize. So, let's get on with Luna ... and 
Mars!   

I hope I have accomplished in making things clearer, as well as expressing 
our sincere appreciation to Konstantin for producing the Kepler SR2 
Release with Patches pre-applied, 

Thanks for reading. 





From:        "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com
> 
To:        "'Cross project issues'" <cross-project-issues-dev@eclipse.org
>, 
Date:        04/03/2014 11:50 PM 
Subject:        Re: [cross-project-issues-dev] Kepler SR3 for Java 8? 
Sent by:        cross-project-issues-dev-boun...@eclipse.org 




The Planning Council met yesterday and approved creation of Kepler SR2 
packages with Java 8 patches installed. 
  
https://wiki.eclipse.org/Planning_Council/April_02_2014 
  
Per the planning council resolution, I sent an e-mail to epp-dev giving 
the package maintainers an option to opt-out of this. So far, there has 
been no opt-outs. The deadline to opt-out is by the end of this week. 
Similarly, I send an e-mail to m2e-dev to confirm that there are no 
objections to inclusion of m2e 1.4.1 release to clarify previous 
statements made on this thread. Igor Fedorenko has indicated that they 
have no objections. 
  
In the meantime, I wrote a script to do the necessary work and the 
packages are available now. 
  
Of the twelve Kepler SR2 packages, three (cpp, parallel and testing) do 
not contain any of the patched components and are excluded from this 
effort. 
  
Packages 
======================== 
  
I am reusing Sapphire?s Hudson instance to build these packages as I am 
not an EPP committer. 
  
https://hudson.eclipse.org/sapphire/job/Java-8-Packages/lastSuccessfulBuild/artifact/releng/java-8/packages/
 

  
Script 
======================== 
  
https://hudson.eclipse.org/sapphire/job/Java-8-Packages/lastSuccessfulBuild/artifact/releng/java-8/build.xml
 

  
The script downloads all of its own dependencies, including ant-contrib 
and the various Eclipse bits. All you need to run it is Ant. Copy the 
script to an empty folder and execute "ant" from this folder. 
  
The part of the script that takes the longest is the download of the 
Kepler SR2 packages, but the downloads are cached so that if something 
causes the script to abort in the middle, you will not need to re-download 
everything. 
  
The Kepler SR2 packages are checksum verified after the download or after 
fetching from cache. 
  
For each of JDT, PDE, WTP and M2E, the script installs the patch/update if 
the target is found. 
  
Downloads Page 
======================== 
  
It would be good to start working on the required changes to the downloads 
page. I opened a bug to track this portion of the effort. 
  
https://bugs.eclipse.org/bugs/show_bug.cgi?id=431955 
  
My recommendation is to add ?Java 8? as a tab between ?Packages? and 
?Developer Builds?. 
  
On a somewhat unrelated note, I think the existing tab labels could be 
improved? 
  
Packages ? This does not adequately define the content found on that tab 
since all of the tabs contain packages. How about ?Stable? instead? 
  
Developer Builds ? This does not define which stream the builds are from. 
That is, this tab does not lead to developer builds from the maintenance 
stream nor to i-builds, etc. How about ?Luna M6? instead? 
  
If the above proposal is accepted, the tabs would be? Stable, Java 8, Luna 
M6 
  
Final Steps 
======================== 
  
Per the planning council resolution, no sign-offs are required from 
package maintainers. I have done a few basic sanity checks on a couple of 
packages, but I am mostly relying on automation to ensure the integrity of 
these packages. If anyone would like to conduct a few tests before these 
packages are made public, you have until the end of this week to do so. 
  
On Monday, I will need help from an EPP committer or a webmaster to move 
the packages to their final location. I am not an EPP committer, so I 
don?t have write access to that area of the downloads server. Does anyone 
wish to volunteer ahead of time to help me with this? I recommend the 
following path? 
  
/technology/epp/downloads/release/kepler/SR2-Java8/ 
  
Once the mirrors have been given adequate time to sync, the downloads page 
changes can be made public and the new packages publicly announced. I hope 
that we can make this happen by early next week. 
  
Thanks, 
  
- Konstantin 
  
  
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
Konstantin Komissarchik
Sent: Thursday, March 27, 2014 7:45 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Kepler SR3 for Java 8? 
  
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: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] 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: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Konstantin 
Komissarchik [konstantin.komissarc...@oracle.com]
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: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug 
Schaefer
Sent: Thursday, March 27, 2014 12:35 PM
To: mike.milinkov...@eclipse.org; 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: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Mike 
Milinkovich [mike.milinkov...@eclipse.org]
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
mike.milinkov...@eclipse.org
+1.613.220.3223_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to