A service release never requires a review (nor does it require an IP Log review). So, yes, just create a release record and you're good-to-go.
IMHO a release that only updates from the EPL-1.0 to EPL-2.0 is a service release. I, naturally, defer to a project's PMC if they have a different opinion. Wayne On Mon, Feb 10, 2020 at 12:38 AM Ed Merks <ed.me...@gmail.com> wrote: > Wayne, > > Correct me if I'm wrong, but if the new bits being contributed are just a > service release then no review is required, only the release record, > correct? > > On 09.02.2020 18:15, Wayne Beaton wrote: > > Updating to the EPL-2.0 (and, by extension, the SUA 2.0) is not a > simultaneous release participation requirement, it's a general requirement. > > I haven't been as noisy as I should have been on this forum. Instead, I've > been working with individual projects as they engage in the release > process. I'd hoped that we'd have picked up everybody by now, but that > clearly hasn't happened: either I've missed doing this for some projects, > neglected to follow up, or those projects simply haven't engaged in a > release review in a while. There has been plenty of noise about this, but > certainly not enough on this channel. I'll change that. > > I'll backpedal a bit then... if it is possible for this release to update > from EPL-1.0 to EPL-2.0 (without adding risk to your release), then please > do so. If not, add it as a plan item for your next release. If your project > is not planning any releases and is still using EPL-1.0, please plan a > service release for 2020-06 with the license upgrade. > > While have your attention, I'll reinforce... > > If you are adding new bits to 2020-03, you need to create a release record > for that new release. If you have not engaged in a release review within a > year of the release date, you need to schedule a release review. If you > have engaged in a successful release review within one year of your release > date, then you do not have to engage in a release review or submit your IP > Log for review. If you are not sure whether or not your intellectual > property is being properly tracked, go ahead and submit your IP Log and > I'll have a look. > > Wayne > > On Sat, Feb 8, 2020 at 4:12 AM Ed Merks <ed.me...@gmail.com> wrote: > >> Wayne, >> >> Are you suggesting that SUA 2.0 is a new participation requirement? It >> seems to me merely a very-nice-to-have. At this point I would just be >> happy if there were no corrupted variants of SUA 1.0 and SUA 1.1: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=553881 >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=553883 >> >> The odds that the 20 features using SUA 1.0 and the 365 features using >> SUA 1.1 will all migrate to SUA 2.0 before the 2020-03 release, without >> introducing new errors, seem beyond remote to me. >> >> All, >> >> Note that not only were the two license problems above not fixed for M2, >> the signing problems were also not fixed: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559739 >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559740 >> >> On the plus side, although the Eclipse Eierlegende Wollmilchsau remains a >> horrible beast: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=483982 >> >> At least it launches successfully again: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559317 >> >> Of course this is only the case after waiting some minutes for the >> workspace dialog prompt, hoping my computer doesn't catch on fire in the >> process, and then waiting another minute for the IDE actually rear its ugly >> head. >> >> At this point, the Error Log is very well populated: >> >> https://bugs.eclipse.org/bugs/attachment.cgi?id=281750&action=edit >> >> Most interesting is that clicking an error log entry will always create a >> new one: >> >> org.eclipse.core.runtime.CoreException: No property tester contributes >> a property org.eclipse.tcf.te.launch.ui.model.canDelete to type class >> org.eclipse.ui.internal.views.log.LogEntry >> >> Regards, >> Ed >> On 07.02.2020 23:07, Wayne Beaton wrote: >> >> Hey folks! >> >> Today is the M2 date for the simultaneous release. I'll be assembling >> the project participation information shortly. >> >> If you are planning to contribute new bits to the 2020-03 simultaneous >> release, and have not already done so, please create a release record as >> soon as possible. It'll be much easier for everybody (especially me) if you >> can get this done before I start assembling the participation list (if the >> information is there, then it will be far more likely that I get it right >> the first time and we can avoid the back-and-forth of fixing things after >> the fact). There is help in the handbook >> <https://www.eclipse.org/projects/handbook/#release>. >> >> Please make sure that your content has the latest SUA and that, if your >> project is currently using the EPL-1.0, you update to the EPL-2.0. If you >> need help with this, please let me know (there's a lot of useful >> information for this on Bug 530393 >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=530393>). >> >> You need only engage in a release review if you have not done so with one >> year of your release date. If you do need to engage in a release review, >> please engage in the workflow at your earliest convenience. The IP Log >> submission deadline is February 28/2020 (M3). >> >> Note that, whether or not you engage in a release review, you are >> required to implement the IP Policy at all times. Further, it is a >> simultaneous release requirement that all third party content be consumed >> through Eclipse Orbit. >> >> The IP Policy was updated in the fall. In practical terms for >> simultaneous release participants, this means that you no longer need to >> create piggyback CQs. There's more background in a Reviewing Third Party >> Content blog post >> <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/>. >> More information regarding how our processes are being updated will be >> coming shortly. >> >> You have likely heard that the Eclipse Planning Council was removed from >> the Bylaws of the Eclipse Foundation. This does not mean that the Planning >> Council no longer exists, only that it is no longer governed directly by >> the bylaws. The Planning Council is still very much the primary authority >> with regard to oversight of the simultaneous release. >> >> Thanks, >> >> Wayne >> -- >> >> Wayne Beaton >> >> Director of Open Source Projects | Eclipse Foundation, Inc. >> >> _______________________________________________ >> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, >> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > -- > > Wayne Beaton > > Director of Open Source Projects | Eclipse Foundation, Inc. > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc.
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev