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 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
 
From: Ed Merks <ed.me...@gmail.com> 
Sent: 08 January 2020 12:23
To: 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> 
Sent: 08 January 2020 11:22
To: 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:
  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>
Sent by: platform-releng-dev-boun...@eclipse.org
To: platform-dev@eclipse.org, eclipse-...@eclipse.org, 
equinox-...@eclipse.org, 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-...@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
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



_______________________________________________
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

Reply via email to