[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] Improving license check for dependencies
|
On 4/2/20 6:39 AM, Wayne Beaton wrote:
> The +1 comes from the PMC before the Eclipse IP Team engages. When the
> PMC gives a -1, the Eclipse IP Team would not engage in their review.
>
> The intent is to have the PMC decide whether or not the CQ makes
> technical sense. Specifically, the IP Team depends on the PMC to confirm
> that the requested dependency is indeed, for example, a prerequisite
> (and not, say, a works with). The EMO and IP Team are not generally able
> to make that assessment.
This assessment, however, doesn't seem to be relevant anymore with the
new IP policy, or is it? The license compatibility check is done (and
needed) only for pre-req deps while I can basically use whatever I want
for build/test and as works-with, right?
So I am having a hard time seeing why the PMC needs to be involved in
the CQ process anymore, given that we have tooling in the build process
that can determine which deps require a (new) CQ and which don't.
> The engagement from the PMC also gives the IP
> Team a hook into the PMC the event that they need assistance in working
> through issues encountered in their review (when they need more help
> than the project team can provide).
>
> Note that there is precedence for PMCs giving -1
> <https://dev.eclipse.org/ipzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=PMC_Approved->.
>
> Wayne
>
> On Wed, Apr 1, 2020 at 6:53 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx
> <mailto:emijiang6@xxxxxxxxxxxxxx>> wrote:
>
> +1 on removing PMC approval! I think it is a bottle neck and I am
> not sure why they want to -1 if Eclipse Foundation approves the
> dependencies. Has any -1 been cast before?
>
> Emily
>
>
> On Wed, Apr 1, 2020 at 11:21 PM Wayne Beaton
> <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>
> No. PMC approval of the IP log is not currently required. PMC
> approval is required for all release reviews.
>
> Wayne
>
> On Fri, Mar 20, 2020, 11:12 Daniel Megert,
> <daniel_megert@xxxxxxxxxx <mailto:daniel_megert@xxxxxxxxxx>> wrote:
>
> > To address Dani's issues of Eclipse PMC case it seems the
> Eclipse PMC may add a requirement of a +1 of the IP Log
> Review instead?
> This is already required today for all IP Log reviews..
>
> Dani
>
>
>
> From: Jonah Graham <jonah@xxxxxxxxxxxxxxxx
> <mailto:jonah@xxxxxxxxxxxxxxxx>>
> To: "eclipse.org-architecture-council"
> <eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>>
> Date: 20.03.2020 15:25
> Subject: [EXTERNAL] Re:
> [eclipse.org-architecture-council] Improving license check
> for dependencies
> Sent by:
> eclipse.org-architecture-council-bounces@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx>
> ------------------------------------------------------------------------
>
>
>
> My understanding with the new IP policies is that the effect
> of PMC involvement in CQ process was going to disappear
> naturally anyway. As CQs only need to be created for the
> first project that wants a new dependency*, all other
> projects can just use the dependency so there is no CQ and
> no PMC involved. Therefore, for example, the Eclipse PMC,
> can no longer rely on CQs to track new dependencies in their
> collective projects.
>
> Therefore it seems to me if we have this new IP policy in
> place, turning off the PMC involvement now makes sense.
>
> To address Dani's issues of Eclipse PMC case it seems the
> Eclipse PMC may add a requirement of a +1 of the IP Log
> Review instead?
>
> * And in the case it is Clearly Defined already, then a CQ
> isn't needed even in this case.
>
> Jonah
>
>
>
> ~~~
> Jonah Graham
> Kichwa Coders_
> __www.kichwacoders.com_ <http://www.kichwacoders.com>
>
>
> On Fri, 20 Mar 2020 at 08:35, Jim Hughes <_jnh5y@ccri.com_
> <mailto:jnh5y@xxxxxxxx>> wrote:
>
> Hi all,
>
> On the PMC approval front, I think I'm hearing that I could
> work with
> the LocationTech PMC to change our ROE to allow for
> self-approvals of
> CQs?
>
> That'd mean that as I enter a CQ, I'd just check the box
> myself, and
> then it'd be off to the races?
>
> Seems like a nice, neat, local solution to that issue.
> Shouldn't
> require anybody else's work, etc.
>
> Thoughts?
>
> Jim
>
> On 2020-03-20 08:05, Gunnar Wagenknecht wrote:
> >> On Mar 20, 2020, at 11:43, Aleksandar Kurtakov <_akurtako@redhat.com_ <mailto:akurtako@xxxxxxxxxx>>
> >> wrote:
> >
> >> On Fri, Mar 20, 2020 at 9:58 AM Daniel Megert
> >> <_daniel_megert@xxxxxx.com_
> <mailto:daniel_megert@xxxxxxxxxx>> wrote:
> >> 1. Remove the need to get PMC approval.
> >>
> >> As a Tools PMC representative this would be very welcome.
> >>
> >> I agree for the Tools PMC but other PMCs know their projects in detail
> >> and are responsive, like e.g. the PMC of the Eclipse Project. It
> >> should be left to each PMC to say whether they require CQ approval or
> >> not.
> >>
> >> But this would require extra development on the ipzilla side. If
> >> Foundation has the manpower to allow each PMC to set such setting
> >> fine. If not we can not penalize all other PMCs for the need of one.
> >> Rather we (Eclipse PMC) would have to find a way to keep track that on
> >> our side.
> >
> >
> > Hmm ... there might be a workaround. :)
> >
> > The RT PMC requires a representative from each project to join the PMC.
> > The RT PMC has a rule that "self" approvals is not welcomed (eg.
> > release reviews, etc.).
> >
> > However the IP team considers PMC entered CQs as pre-/auto-approved.
> > At least, that was my observation when entering CQs as project lead
> > for an RT project.
> >
> > Having said that, it's up to the PMC to defined the rules of
> > engagement. I know that some PMCs are interested in tight management
> > of the dependencies. Hence the request for PMC approval. In Technology
> > we don't. We basically just check for basic errors and approve every
> > CQ. This becomes a bottleneck sometimes (especially around vacation
> > times).
> >
> > I believe that in theory the IP policy and EDP already allows for
> > delegation and pre-approval as practiced by the RT PMC. It's not
> > codified in the IP tool and requires manual recognition by the IP
> > team, which makes it challenging at scale.
> >
> > -Gunnar
> _______________________________________________
> eclipse.org-architecture-council mailing list_
> __eclipse.org-architecture-council@eclipse.org_
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> _https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council________________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
>
>
> --
> Thanks
> Emily
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
>
>
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation, Inc.
>
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Software Developer - Bosch IoT Hub
Bosch.IO GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch.io
Registered Office: Berlin, Registration Court: Amtsgericht
Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne
Reckling
