[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] 4.15 M1 milestone week reminders
|
I agree with the
license related changes but all other changes to https are fine with me
and will not be reverted.DaniFrom:
Ed
Merks <ed.merks@xxxxxxxxx>To:
platform-dev@xxxxxxxxxxxDate:
08.01.2020
11:29Subject:
[EXTERNAL]
Re: [platform-dev] 4.15 M1 milestone week remindersSent
by: platform-dev-bounces@xxxxxxxxxxx
Sravan,The http://git.eclipse.org403 was a bad bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=558828Its current behavior of a 301 redirection
to https://git.eclipse.orgis 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.orgmaking 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.eclipsenot 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.setupand redirects it to display https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setupso one has to assume that even if http://www.eclipse.orgchanged 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.merks@xxxxxxxxx>
Sent: 08 January 2020 12:23
To: platform-dev@xxxxxxxxxxx
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.merks@xxxxxxxxx>
Sent: 08 January 2020 11:22
To: platform-dev@xxxxxxxxxxx
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: https://bugs.eclipse.org/bugs/show_bug.cgi?id=558773We'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.htmlPlease do not drop a build that
is in this state into SimRel 2020-03 for M1.Regards,
EdOn
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_gupta@xxxxxxxxxx>
Sent by: platform-releng-dev-bounces@xxxxxxxxxxx
To: platform-dev@xxxxxxxxxxx,
eclipse-dev@xxxxxxxxxxx,
equinox-dev@xxxxxxxxxxx,
platform-releng-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxxTo
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@xxxxxxxxxxxTo
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev