Re: [eclipse.org-architecture-council] Who Needs Piggyback CQs?

[Ed Merks <ed.merks@xxxxxxxxx>]

Gunnar,

Comments below.

On 31/03/2015 8:57 PM, Gunnar Wagenknecht wrote:

On 31/03/2015 5:08 PM, Gunnar Wagenknecht wrote:

Ed,

Here are my thoughts on this:

+1 on removing the need to _manually_ manage PB CQs
-1 on removing PB CQs in general without replacing them with a suitable reporting/tracking mechanism

An IP log is not suitable?  I think I'll have a hard time getting a process in place where CQs don't require approval, except maybe for PB CQs, so another approach is to automate their creation and approval.  But as I say this I'm confused what automatically generated, automatically approve CQ buys you...

Ok, so maybe I'm splitting hairs, but they way I read what I wrote should leave room for removing PB CQs. But frankly, I don't think they are the real problem. If PB CQs are required from a technical perspective to make IP Log generation and management feasible for the IP team then fine.

Yes, personally I was primarily focused on automation.   One could imagine generating such CQs automatically and if approval were not necessary that would be that.  But it was pointed out that PB CQs are an implementation detail of the IP policy, not hard coded in the policy itself, so that detail could be changed without changing the policy itself.  Policy changes require board approval.

That being said, there were 8 PB CQs requiring my attention this just morning, and when we filed a PB CQ for Oomph's dependency, we waited 2 months for PMC approval.  When approved it was pointed out that a new version had become available.  We don't care which version we use, we specify it strictly, and we point at Orbit to fetch it, so once a new version shows up, we just end up using it, without explicit action (including without filing a new CQ).  Therese aren't major problems, but I multiply them out over our large community, and I see definite room for improvement.

 IMHO the issue is that a PMC has to deal with re-use from Orbit dependencies and I'm absolutely in favor of anything that will remove that management from the PMC (and possibly the projects).

But maybe the motivation for removing PB CQs is different? 

The motivations are three fold:

1. Eliminate unnecessary PMC involvement and delays.
   
2. Eliminate unnecessary work for project leads.
3. Eliminate unnecessary work for the IP team.
   
4. Improve accuracy of the tracking.

(2) I prefer to keep the IP Log for listing such usage as per (1).

But you want them to refer to PB CQs, not directly to the original CQs?

No preference here. I would consider this an implementation detail of the IP database.

That's what I figured.

(3) The IP process should change to an "opt-in" model for projects on a "per-release" base.

I expect this is a no go.   If you don't want to follow the IP process you don't belong at Eclipse...

Keep in mind that the IP process applies to *all* forges not just www.eclipse.org projects. 

Definitely, e.g., Xtext move the code base to github.

Disclaimer: It's my understanding that the change process is the same independent from the size of the change.

It depends on what's being changed.  If it's a detail of how the policy is implemented, it's mostly to the EMO's discretion.   If it's a change to the policy, the process involves much yacking at the committee followed a board approval vote, which must be preceded by much yacking at corporate headquarters among the lawyers and lawyer-like.  The latter's duration is strongly influenced by the size and nature of the change...

 Probably naive but that's why I thought "hey, when touch it now why don't do it proper and review all?" Maybe it's also my fear that if change goes through this year then another few years will have to pass before people will allow changing it again.

It comes down to redistribution.  If it's distributed from Eclipse it must be IP clean.  If it's hosted elsewhere and distributed elsewhere it's not an Eclipse project...

I have the feeling that with the growing number of forges and projects the IP backlog is growing too.

Yes, it's a fact.

 I also don't think the IP team can grow the same way.

I suppose they could, but the money supply to fund that certainly doesn't grow the same way.

 Do all the forges really need the full IP process? I think there should be an open discussion. I would actually love to see requirements and arguments from each board member. A few years ago "Adopt and Change" was the mantra for processes at Eclipse. After over a decade ... why not the IP process too?

We are in the process of amending it right now, but for other reasons.   The board does public minutes, but board meetings are confidential except for the approved minutes.  In any case, I know I personally would not be in favor of two classes of projects, i.e., IP reviewed ones and non-IP approved projects.  To me it's a formula for yet more complexity and confusion.  Clearly an IP reviewed project can't use the results of a non-IP approved code base, so this would induce a schism, and water down the IP clean brand that is Eclipse.

-Gunnar
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.