[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Kepler SR2 with Patches pre-installed

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

Dani



From:        Doug Schaefer <dschaefer@xxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        04.04.2014 16:26
Subject:        Re: [cross-project-issues-dev] Kepler SR2 with Patches pre-installed
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




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-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Konstantin Komissarchik [konstantin.komissarchik@xxxxxxxxxx]
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-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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.komissarchik@xxxxxxxxxx>
To:        
"'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        
04/03/2014 11:50 PM
Subject:        
Re: [cross-project-issues-dev] Kepler SR3 for Java 8?
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx





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-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Konstantin Komissarchik [konstantin.komissarchik@xxxxxxxxxx]
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-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent:
Thursday, March 27, 2014 12:35 PM
To:
mike.milinkovich@xxxxxxxxxxx; 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-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Mike Milinkovich [mike.milinkovich@xxxxxxxxxxx]
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.milinkovich@xxxxxxxxxxx
+1.613.220.3223
_______________________________________________
cross-project-issues-dev mailing list

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