Bugzilla – Full Text Bug Listing
| Summary: | IPZilla doesn't support project components | ||
|---|---|---|---|
| Product: | Community | Reporter: | Eike Stepper <stepper> |
| Component: | IPZilla | Assignee: | Eclipse Foundation IPZilla inbox <foundation.ipzilla-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P2 | CC: | austin.riddle, b.kolb, barb.cochrane, barbier.gabriel, benoit.langlois, bokowski, com-eclipse-dot-org, ed, francisu, janet.campbell, jonathan.musset, karl.matthias, Kenn.Hussey, ruediger.herrmann, sebastian.zarnekow, sharon.corbett, soden, wayne.beaton, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 295520 | ||
| Bug Blocks: | 293640, 294607, 294784 | ||
|
Description
Eike Stepper
IPZilla doesn't support project components, so for now you'll need to file the CQ under the parent project, EMF. Let's leave this bug open to discuss adding that functionality to IPZilla. Yes, I already filed the CQ against EMF ;-) I just thought you might be interested in this mismatch between the portal and IPZilla... In the meantime I think I ought to lock IPZilla features out for components in the Portal to keep from confusing everyone. > In the meantime I think I ought to lock IPZilla features out for components in
> the Portal to keep from confusing everyone.
If the Portal can support unlimited nested components, then perhaps we should simply consider opening CQs against the parent project and call it a day. To support one level of components in IPZilla is doable, to support unlimited nested components would be the expense of everyone's sanity.
(In reply to comment #4) > > In the meantime I think I ought to lock IPZilla features out for components in > > the Portal to keep from confusing everyone. > > If the Portal can support unlimited nested components, then perhaps we should > simply consider opening CQs against the parent project and call it a day. To > support one level of components in IPZilla is doable, to support unlimited > nested components would be the expense of everyone's sanity. Actually, the Portal only supports three layers. Writing the code to support unlimited layers actually introduces huge overhead in the SQL queries, so I didn't do that. So as I read your suggestion, it would be to make the functionality show up for components, but file the CQ against the parent project? > Actually, the Portal only supports three layers.
Three layers of components, or three layers total (such as top-level.project.component) ? If it's three layers total (one layer for components) then we can make that work in IPZilla, which would likely be the best solution.
(In reply to comment #6) > > Actually, the Portal only supports three layers. > > Three layers of components, or three layers total (such as > top-level.project.component) ? If it's three layers total (one layer for > components) then we can make that work in IPZilla, which would likely be the > best solution. > The development process and the Portal currently support top-level.project.component. Oh, great, we can probably support this easily in IPZilla then. *** Bug 280915 has been marked as a duplicate of this bug. *** *** Bug 281584 has been marked as a duplicate of this bug. *** (In reply to comment #8) > Oh, great, we can probably support this easily in IPZilla then. When will this happen? I ran into this problem, again ;-( *** Bug 286802 has been marked as a duplicate of this bug. *** *** Bug 287286 has been marked as a duplicate of this bug. *** *** Bug 289299 has been marked as a duplicate of this bug. *** So does this mean I can't add a CQ until this bug is resolved? Or is there a workaround? (In reply to comment #15) > So does this mean I can't add a CQ until this bug is resolved? Or is there a > workaround? Please file it against the platform itself. Is there any technical reason why we can't just add the components to IPZilla? Denis just showed me the query that's used to populate IPZilla; it specifically excludes anything marked as a "component" in the Foundation database (it further restricts itself to "level 2" entries). Is there any technical reason why modeling.emf.net4j cannot be represented in IPZilla? Is it enough to simply change the query that populates IPZilla, and we're off? Or, possibly, relax the "level 2" requirement and turn off the "is-component" option for individual project/components? I think we can do this while still respecting the "three levels" restriction. What would break if modeling.emf.net4j is added to IPZilla? Or is it more the case that fewer things would break? Rather than adding code to the portal to handle the special case of components, would it be better to just recognize the components as being the equivalent of projects? I know that the IP Team would prefer that each project/component (they are supposed to be the same thing now) have its own IPZilla identity. The upside is that we would have better understanding of which CQs really belong to which components. The downside is that many of these "level 3" projects will have to add piggyback CQs for CQs they're currently "inheriting" from their parent. We would have to roll this out one-project-at-a-time. (In reply to comment #17) > I think we can do this while still respecting the "three levels" restriction. Before making any changes in the number of levels supported in IPZilla, I'd like to see us decide how many levels we will support generally. If we are going to support three and three only, then I would suggest that we standardize on this number of levels across the project structure, portal, IPZilla and any other areas where this kind of granularity is relevant. If we deviate from this approach (and contemplate different levels of granularity in each of these areas), then we have to determine how we are going to handle the deviations. Just as a data point, the Portal and the Foundation DB code only properly support three levels. I just saw that some projects have been entered with 4 levels in the DB and this is likely to seriously make headaches. (In reply to comment #19) > Just as a data point, the Portal and the Foundation DB code only properly > support three levels. I just saw that some projects have been entered with 4 > levels in the DB and this is likely to seriously make headaches. For purposes of my own education, can you point me to a specific place where something breaks with four levels? Is there anything that will break as a result of having a mix of two- and three-level project names in IPZilla? (In reply to comment #20) > (In reply to comment #19) > > Just as a data point, the Portal and the Foundation DB code only properly > > support three levels. I just saw that some projects have been entered with 4 > > levels in the DB and this is likely to seriously make headaches. > > For purposes of my own education, can you point me to a specific place where > something breaks with four levels? I'm not sure if you're referring specifically to IPZilla here or not. I am not the expert on IPZilla, my comments were in reference to the Foundation DB and the Portal. > Is there anything that will break as a result of having a mix of two- and > three-level project names in IPZilla? Well at the moment I think all the IPzilla stuff in the Portal may need updates regardless since something will be changing here. But I don't know that code at all since I never worked on it. Wayne, Should this bug be tagged "IPZilla" or is there a more appropriate bucket given the scope of the discussion (IPZilla, Foundation DB, Project structure, Portal)? Janet I think it's most closely linked to IPZilla. Can we leave it here until we can think of a compelling reason to move it elsewhere? This issue is currently blocking Modeling third-level projects from submitting CQs. (In reply to comment #24) > This issue is currently blocking Modeling third-level projects from submitting > CQs. Can they be submitted by the next up the chain? I don't advocate that on a permanent basis, but since we don't have a solution, that's what we used to have them do. > I just saw that some projects have been entered with 4 > levels in the DB and this is likely to seriously make headaches. I don't see any. Currently, the deepest I see is 3. (In reply to comment #18) > Before making any changes in the number of levels supported in IPZilla, I'd > like to see us decide how many levels we will support generally. I suggest we make it 3. No deeper. Wayne, Janet, do you agree? (In reply to comment #26) > > I just saw that some projects have been entered with 4 > > levels in the DB and this is likely to seriously make headaches. > > I don't see any. Currently, the deepest I see is 3. You may be referring to modeling.mdt.imm.releng. It is listed as level 3, and its parent is modeling.mdt. The project short name is "imm.releng". Confusing? Perhaps. But a level 3 nonetheless. (In reply to comment #26) > I suggest we make it 3. No deeper. Wayne, Janet, do you agree? Sounds reasonable to me. The modeling project is probably the biggest test of project nesting, and they seem to be able to get along with three levels. I think also, that I can successfully argue that if there is some need to have more than three levels of depth then mere mortal understanding of what's going on gets sufficiently complicated. How twisted a statement is that? (In reply to comment #27) > You may be referring to modeling.mdt.imm.releng. It is listed as level 3, and > its parent is modeling.mdt. The project short name is "imm.releng". > Confusing? Perhaps. But a level 3 nonetheless. This is a really bad idea. If we're going to use a dot notation to represent a project for our records, it really needs to not have a dot that doesn't mean anything. This should be modeling.mdt.imm-releng or something like that. This not only is confusing to look at, but makes it so that every piece of code that deals with projects has to look up the parent every single time, rather than being able to parse the string. (In reply to comment #28) > (In reply to comment #26) > > I suggest we make it 3. No deeper. Wayne, Janet, do you agree? > > Sounds reasonable to me. +1 > This is a really bad idea. If we're going to use a dot notation to represent a
> project for our records, it really needs to not have a dot that doesn't mean
> anything. This should be modeling.mdt.imm-releng or something like that. This
> not only is confusing to look at, but makes it so that every piece of code that
> deals with projects has to look up the parent every single time, rather than
> being able to parse the string.
Agreed. Please open a bug against the NPPR to catch/prevent this, make the bug blocking this one. Set priority = P1. Let's get it fixed ASAP.
(In reply to comment #26) > I suggest we make it 3. No deeper. Wayne, Janet, do you agree? I'd like to explore a couple of things a little further before we go down this path: (1) I'd like to understand the implications on committers and the IP Team of increased CQ flow resulting from such a change. I think it's important we also understand how the benefits of extending the number of supported levels would exceed the benefits of (for example) leaving the number of levels supported the same and placing an informative note for committers asking them to submit CQs at the 2nd tier if in fact they are further nested. The latter approach may have some implications form an IP log standpoint which we would also need to discuss within this context. As I understand it, this is the workaround being used now. Separate, but related, perhaps we find a way to advise committers to use this approach while we work through these issues - through the portal UI for example. (2) I'd like to discuss the possibility of changing our approach to CQ submission. One CQ per requirement. The use of the re-use of CQs would be identified through the IP Log tool, rather than through the addition of CQs by project. Is this something that could easily be implemented in the IP log tool? I'll set up a meeting with us all in a room together to better flush things out. Janet *** Bug 293640 has been marked as a duplicate of this bug. *** *** Bug 294607 has been marked as a duplicate of this bug. *** (In reply to comment #32) > (In reply to comment #26) Additional questions for our meeting: - We have all CQs at the second level. There are no CQs at a third level right now. There are approximately 2167 approved CQs in the system. - We now have components at the third level (and there has been some suggestion that this could be extended beyond three levels). I believe there are now approximately 100+ components at the third level now. If we were to extend IPZilla support to the third level, what is the proposed implementation plan to limit the impact on the IP Team and community of duplicating (where more than one component at the third level is using an approved CQ) and reallocating (where only one third level component is using a CQ) the existing approved CQs? How would CQ entry/moves be handled? How would the IP Logs for the Projects be affected? Janet (In reply to comment #35) > If we were to extend IPZilla support to the third level, what is the proposed > implementation plan to limit the impact on the IP Team and community of > duplicating (where more than one component at the third level is using an > approved CQ) and reallocating (where only one third level component is using a > CQ) the existing approved CQs? How would CQ entry/moves be handled? How would > the IP Logs for the Projects be affected? I'm not sure if my opinion carries any weight with regard to policy, but personally I'd just leave all the existing ones alone and just make the change for all new CQs. Thus the impact on your team would be more or less nothing. Just my $.02. *** Bug 296102 has been marked as a duplicate of this bug. *** (In reply to comment #36) > (In reply to comment #35) > I'm not sure if my opinion carries any weight with regard to policy, but > personally I'd just leave all the existing ones alone and just make the change > for all new CQs. Thus the impact on your team would be more or less nothing. > Just my $.02. At the end of the day, I believe taking that approach would be confusing to the Projects - we need to be consistent. Also, I expect that it will create difficulties when it comes to the creation of the IP log with the automated tool. (In reply to comment #38) > (In reply to comment #36) > > (In reply to comment #35) > > I'm not sure if my opinion carries any weight with regard to policy, but > > personally I'd just leave all the existing ones alone and just make the change > > for all new CQs. Thus the impact on your team would be more or less nothing. > > Just my $.02. > > At the end of the day, I believe taking that approach would be confusing to the > Projects - we need to be consistent. Also, I expect that it will create > difficulties when it comes to the creation of the IP log with the automated > tool. It seems worth considering that it might be more confusing to migrate so many CQs (not to mention terribly time consuming for projects as well as Foundation staff)? If we communicate clearly to the projects via all of our channels (blogs, eclipse.org-committers list, etc), and change the Portal so _new_ CQs can only be opened at the component level, then it would be hard for them to do the wrong thing. Some people still do the wrong thing now, so of course there will be a few stragglers who are confused. But it seems to me that it wouldn't be any worse than normal and would save us and projects huge pains. (In reply to comment #39) > (In reply to comment #38) > > (In reply to comment #36) > > > (In reply to comment #35) I don't believe that the approach you suggest meets our needs from an IP Log standpoint. Moreover, it just begs the question in my mind why we would migrate to three levels at all. In any event, that's why we need to get together in a room to discuss. Working on that :) *** Bug 297618 has been marked as a duplicate of this bug. *** *** Bug 297992 has been marked as a duplicate of this bug. *** IPZilla now supports project components. |