Dani,
Yes, my comments and concerns are purely and only related to the license
text in the products. In their usual diligent manner, our tireless
release engineers have already addressed that concern.
Last night's build is good again:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.15-I-builds/http___download.eclipse.org_eclipse_updates_4.15-I-builds_I20200108-0600.html
Thanks folks!
It would of course be great if ECF could move to EPL 2.0 and also use
SUA 2.0, but alas, that's not the case.
Any other conversion from http -> https in code or in documentation is
of course fine and good, though a word of caution is in order because,
for example, my older Java 8 implementation cannot read from
archive.eclipse.org via https:
org.eclipse.equinox.p2.core.ProvisionException: Unable to read
repository at
https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/content.xml.
at
org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:247)
at
org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:69)
at
org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:89)
at
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:63)
at
org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:775)
at
org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:676)
at
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:110)
at
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:105)
at
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:94)
at
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:60)
at
org.eclipse.cbi.p2repo.aggregator.p2.util.MetadataRepositoryResourceImpl$RepositoryLoaderJob.run(MetadataRepositoryResourceImpl.java:486)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396)
at
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
at
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
at
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:373)
at
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:394)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:246)
at
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69)
... 1 more
Most likely a root certificate problem because it works fine with the
231 Java 8 version.
Regards,
Ed
On 08.01.2020 15:30, Daniel Megert wrote:
I agree with the license related changes but all other changes to
https are fine with me and will not be reverted.
Dani
From: Ed Merks <ed.me...@gmail.com>
To: platform-dev@eclipse.org
Date: 08.01.2020 11:29
Subject: [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone week reminders
Sent by: platform-dev-boun...@eclipse.org
------------------------------------------------------------------------
Sravan,
The _http://git.eclipse.org_ <http://git.eclipse.org/>403 was a bad bug:
_https://bugs.eclipse.org/bugs/show_bug.cgi?id=558828_
Its current behavior of a 301 redirection to _https://git.eclipse.org_
<https://git.eclipse.org/>is argued to be a feature that we should
embrace. I will not argue that point, other than to point out that
it's just annoying that a simple URL connection fails. But one could
call java.net.HttpURLConnection.setFollowRedirects(boolean) globally
or java.net.HttpURLConnection.setInstanceFollowRedirects(boolean) on
the connection instance so that the 301 is followed...
Imagine now _http://www.eclipse.org_ <http://www.eclipse.org/>making
the same change. Every browser would just follow the redirect.
Imagine that it just stops working entirely as in the 403 case; that's
just a bug and if we needed to work around that, we'd need to revisit
every wiki page and every scrap of documentation to change all the
URLs everywhere. It seems to me that this is most clearly not feasible
activity and would be addressed immediately.
So while I do understand your thinking and logic for why you changed
this in the product definitions (and I definitely *greatly appreciate
*all the hard work you folks to do keep releng working), to argue that
we should/must change the legal text in anticipation of
_http://www.eclipse_not working reasonably or in anticipation of some
software being unable to follow redirects is just too much of a leap
from that starting premise. Even the internal browser can load
_http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup_and
redirects it to display
_https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup_so
one has to assume that even if _http://www.eclipse.org_
<http://www.eclipse.org/>changed its behavior to 301, it would
continue to work properly for browsing purposes at the very least (and
for most purposes for that matter).
So I would argue that we avoid doing anything that is highly likely to
result in yet more license prompts for the users of Eclipse. I.e.,
just leave the SUA 2.0 alone and revisit it if/when there is a
substantive reason to change the meaningful content. We all have
better things to do...
Regards,
Ed
On 08.01.2020 09:08, Sravan K Lakkimsetti wrote:
Hi,
To me not able to access license page is a bigger problem. If it is
legal document it should be accessible. By using http we are currently
depending on http->https redirection service available at eclipse
foundation. We also seen this service can go down any time like it
happened on Jan 2, 2020. In my opinion to avoid dependency on
redirection service and single point of failure it is better to move
to https protocol instead of unsecure http. This is the reason I tried
go with https.
What is your suggestion on avoiding the similar failures in future.
How do we proceed?
-Sravan
*From:*Ed Merks _<ed.me...@gmail.com>_ <mailto:ed.me...@gmail.com>*
Sent:* 08 January 2020 12:23*
To:* _platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>*
Subject:* [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone week reminders
Sravan,
If "we" really want to change the license that is currently used by
literally 1000s of features/products, we should change it in the
central license feature first and hope (which is a rather pointless
hope) that all projects rebuild to use the new version and all of them
contribute that to SimRel (which seems unlikely to me given this was
not accomplished in the last 3 months). We'll also need to hope that
all copies everywhere (EPP products, for example) are also changed
(yet again). Then we should expect all users to re-review the new
text because they will be forced to do so. The not-so-impressed user
user can then agree yet again to what is effectively the same license.
To me this all smacks of completely gratuitous work for dozens or
hundreds of people with absolutely zero value because browsers switch
to https automatically when visiting a web link and even if not, any
concerned user can make sure they view links using https if they're
concerned that they might be presented with a bogus/hacked bit of
legal documentation.
In the end, it's really a very inappropriate plan for the platform to
make this decision for everyone without consulting anyone. After all,
it's a legal document so is it really your role to decide to alter
it? Moreover, should we not question whether the date needs to be
changed given this is no longer the "November 22, 2017" version of
this legal document?
Regards,
Ed
On 08.01.2020 07:11, Sravan K Lakkimsetti wrote:
In my opinion, we should move towards https instead of depending on
http->https redirection made available by webmaster. We should plan to
move to https in this release.
For M1 I suggest to revert the change. But for M3 we should move to https.
-Sravan
*From:*Ed Merks _<ed.me...@gmail.com>_ <mailto:ed.me...@gmail.com>*
Sent:* 08 January 2020 11:22*
To:* _platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>*
Subject:* [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone week reminders
Noopur,
Please, please revert the changes made to do http -> https conversion
in the license text of all the *.product files that was done in this
Bugzilla:
_h_ <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558773>
We're back to having bogus license variants yet again:
_https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.15-I-builds/index.html_
*Please do not *drop a build that is in this state into SimRel 2020-03
for M1.
Regards,
Ed
On 07.01.2020 16:57, Noopur Gupta wrote:
Hi all,
As mentioned in the reminders e-mail:
*After Monday 18:00 ET, no feature work or unrelated fixes are allowed
-- only regression fixes.*
Please avoid releasing patches that are not important for that
milestone after Monday, 18:00 ET.
For example, here's the git log of the changes that went in
after I20200106-1805 and some of these could have been avoided:
_https://download.eclipse.org/eclipse/downloads/drops4/I20200107-0600/gitLog.php_
Regards,
Noopur
----- Original message -----
From: "Noopur Gupta" _<noopur_gu...@in.ibm.com>_
<mailto:noopur_gu...@in.ibm.com>
Sent by: _platform-releng-dev-bounces@eclipse.org_
<mailto:platform-releng-dev-boun...@eclipse.org>
To: _platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>,
_eclipse-dev@eclipse.org_ <mailto:eclipse-...@eclipse.org>,
_equinox-dev@eclipse.org_ <mailto:equinox-...@eclipse.org>,
_platform-releng-dev@eclipse.org_ <mailto:platform-releng-...@eclipse.org>
Cc:
Subject: [EXTERNAL] [platform-releng-dev] 4.15 M1 milestone week reminders
Date: Fri, Jan 3, 2020 9:50 AM
Hi all,
Next week is the milestone week for *4.15 M1*.
*Monday*: Last day of development (and even then, no "big changes").
After Monday 18:00 ET, no feature work or unrelated fixes are allowed
-- only regression fixes.
*
Tuesday*: All-day test pass. Nobody should develop or fix anything.
Literally spend the entire day testing.
*Wednesday*: Fix day with a focus on fixing regressions found during
the test day (Tuesday). No unrelated fixes. Review and thoroughly test
all commits.
- The last Wednesday build is the release candidate *every team signs
off on Thursday*.
- The "*New and Noteworthy*" entries are /due on Wednesday evening/:
Git repo: _ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git_
Gerrit: _ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git_
Live website: _https://www.eclipse.org/eclipse/news/4.15/_
*Thursday*: Sign-off after re-testing, or at least confirming no
changes have been made to your component's code since the last time
the component was tested well.
*Friday*: Build is officially declared and made available.
- The master branch stays closed until the milestone is officially
released. (That is, it is not enough that your component has signed off.)
Wishing you all a very Happy New Year 2020!
Thanks & Regards,
Noopur
_______________________________________________
platform-releng-dev mailing list_
__platform-releng-dev@eclipse.org_
<mailto:platform-releng-...@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit_
__https://www.eclipse.org/mailman/listinfo/platform-releng-dev_
_______________________________________________
platform-dev mailing list
_platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_https://www.eclipse.org/mailman/listinfo/platform-dev_
_______________________________________________
platform-dev mailing list
_platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_https://www.eclipse.org/mailman/listinfo/platform-dev_
_______________________________________________
platform-dev mailing list
_platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_https://www.eclipse.org/mailman/listinfo/platform-dev________________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
