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

[Doug Schaefer <dschaefer@xxxxxxx>]

I think at the end of the day, we¹re pretty much in agreement that
piggyback CQ¹s can go.

And the sooner the better. I am very afraid that with the increased
workload in Mars that some features are going to be left behind because
the Eclipse IP team is overloaded (the Arduino CDT for example which needs
freemarker, amongst others).

I think the other thing causing havoc is that some projects, CDT for
example, are doing minor releases at the SR¹s. We didn¹t start working on
Mars until after the CQ deadline so we¹re piling on late.

This release frequency thing also needs to figured out. We talked briefly
about it in Burlingame. I¹d still love to see a switch to every six
months. Maybe that would help spread out the IP review workload (or make
it worseŠ).

Doug.

On 2015-03-31, 2:57 PM, "Gunnar Wagenknecht" <gunnar@xxxxxxxxxxxxxxx>
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. 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?
>
>>> (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.
>
>>> (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.
>
>Disclaimer: It's my understanding that the change process is the same
>independent from the size 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.
>
>I have the feeling that with the growing number of forges and projects
>the IP backlog is growing too. I also don't think the IP team can 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?
>
>-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.