Community
Participate
Working Groups
Recently teams have been receiving messages (see below) from the IP team requesting finer-granularity on their CQs and IP logs for Helios. There are a number of issues with this and we need to get clarification from the IP team and EMO to better understand the work requested and its value to the IP process. Examples of the issues are: - There are a number of libs that are used widely by the community (e.g., ICU) or individual projects (e.g., EasyMock). According to this request we will be entering hundreds more CQs to cover this usage. - Many "projects" (aka things formerly call components) do not ship standalone so the finer-granuarlity does not contribute to the clarity or risk mitigation - In the interest of openness, the reason, value and use of this extra work needs to be clearly and broadly communicated if indeed it turns out to be needed. Example of the message at hand: Now that IPzilla supports three levels of granularity, there is a requirement for CQs to be entered at that level. Platform currently has existing CQs that are not aligned at that level. Therefore, in order to prepare for the IP Log submission for Helios; there is some work that must be completed. In order to make this as painless as possible, I知 attaching a spreadsheet of all Platform CQs. There is one blank column where you can identify the correct component. We will then arrange to move them as required within IPzilla. If a CQ is required in more than one place, a Piggyback/Reuse CQ will need to be arranged as we can only move a CQ to one component. Appreciate your help. This work must be completed prior to Helios IP Log submissions.
I think I have found the "community" request that started this... see bug 278901 for details. The capsule summary seems to be, "some projects want to file CQ's at the third tier", and "we need to be consistent", therefore all projects will be forced file CQ's at the third project tier.
I have discussed this with Janet and I believe that we have a resolution that can be consistently applied and should make everybody happy. The short version is something like this: Nested projects that are releasing as part of parent project's release can leave their CQs on the parent project. If an nested chooses to release separately (or move), the CQs corresponding to that project will need to be realigned. e.g. rt.equinox.p2 CQs can stay under rt.equinox so long as rt.equinox.p2 releases as part of rt.equinox. I believe that rt.equinox.scalamodules will probably release separate from the rest of rt.equinox, so any CQs related to rt.equinox.scalamodules will need to be aligned directly with that project. Does this help? Janet and I are crafting a wiki page for this. I'll post a link to the wiki page when it goes live.
(In reply to comment #2) > Janet and I are crafting a wiki page for this. I'll post a link to the wiki > page when it goes live. Wayne, Is this wiki page up yet??
Decided to go for the gusto and create a proper "Contribution Questionnaire" Page. http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire I have included this text on the page: "Nested projects that are distributed as part of a parent project's aggregated distribution can leave their CQs on the parent project. If a nested project chooses to provide an independent distribution (either completely separately, or in addition to the aggregation), the CQs corresponding to that project will need to be realigned. Note that the IP logs for an aggregated distribution can be combined (this is supported by tools)." It needs a little more massaging (I might try to put some 'how long' discussion in there). Comments?
Note that the "Contribution Questionnaire" link on http://www.eclipse.org/legal/ just points to the portal. The text further states "Follow the link to find out more about what we mean by 'significant contribution'. Bug fixes or minor enhancements do not require PMC or EMO approval." which appears to be at least bogus (there is no such discussion on the link) or misleading (I'm concerned about how the second sentence might be interpreted). In the wiki page, I opted to use terms like "Contributions that require the completion of a CQ are identified by the Eclipse IP Due Diligence Process". It might be good to include a sentence along the lines of "Ongoing development by project committers does not generally require a CQ." If this needs to be discussed extensively, I recommend that we open a new bug.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Looks I just forgot to close this.
