Community
Participate
Working Groups
As noted in CQ4034 the search that is driven when 3rd party dependency CQs are raised via the "request" option in the portal fails to find some hits. The particular example in that case was that "sshd" missed CQ3886 in spite of the CQ having "SSHD" in the title. However using the IPZilla search (as described in CQ4034 comment #6) turns up that CQ.
I took a look into this bug and figured out what is going on. The search from the Portal is only looking for CQs that have been approved, both of the CQs you were looking for are in the 'awaiting_analysis ' state and therefore will not show up in the search results. I believe this is the correct behavior as we probably don't want people piggy backing on unapproved CQs. It could be possible with a bit of work to get the Portal to show unapproved CQs with a message indicating the current state of the CQs. This might help reduce the number of duplicate CQs entered. I will leave this type of decision up the legal team as they know more about this process than I do. I am going to mark this bug as 'workforme' for now as this is not really a bug and only has a chance to become an enhancement if the legal team deems it necessary.
Hey Gabe, Bang on; that was definitely the decision we made when we introduced the notion of piggybacking. :-) Now that we have a little bit of experience under our belts, we see a benefit to allowing piggybacks for CQs not yet approved for use (Glyn's situation being a shining example). That said, we would not want to allow piggybacking on CQs that have been "rejected", "withdrawn", "closed"......etc. The "state" and "status" in IPZilla are different; I'm not sure which one (or combination) the portal uses as its guidepost so it may be more effective to have a conversation about this one when you're ready to look at this as a possible enhancement. Thanks! Barb
(In reply to comment #2) > The "state" and "status" in IPZilla are different; I'm not sure which one (or > combination) the portal uses as its guidepost so it may be more effective to > have a conversation about this one when you're ready to look at this as a > possible enhancement. Alright so it looks like this bug has a life after all. Here is the query that is being run from the Portal (for reference more than anything): https://foundation.eclipse.org/ipzilla/buglist.cgi?query_format=advanced&columnlist=bug_id,bug_severity,short_desc&bug_severity=approved&short_desc_type=allwordssubstr&short_desc=KEY_WORDS_LOOKING_FOR So the Portal is looking for bugs where the 'bug_severity' (which is the state of a bug) is 'approved'. Seems I misspoke when I said the Portal didn't find the bugs with a subject of 'SSHD' because their state was 'awaiting_analysis'. The Portal is not picking them up because their state (or bug_severity) is 'new' not 'approved'. Can you get me a list states or statuses that should be available for piggy backing?
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.
I'm going to declare this invalid. We've reimplemented the entire functionality and I'm pretty confident that the search is quite good. I assume that somebody will let me know if I'm horribly mistaken.
