Skip to main content

[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.

Dani



From:        Ed Merks <ed.merks@xxxxxxxxx>
To:        platform-dev@xxxxxxxxxxx
Date:        08.01.2020 11:29
Subject:        [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone week reminders
Sent by:        platform-dev-bounces@xxxxxxxxxxx




Sravan,
The http://git.eclipse.org403 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.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=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_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@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_______________________________________________
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



Back to the top