Sravan,
The
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
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 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
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
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
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=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:
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:
-----
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.
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!
_______________________________________________
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
_______________________________________________
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
|