Jump to: navigation, search

Difference between revisions of "IP Stuff"

Line 19: Line 19:
  
 
Well, we look at a few things so it may be a good idea to parse it out. <br />  
 
Well, we look at a few things so it may be a good idea to parse it out. <br />  
a)  We check your committer list to make sure it matches what we have in our database. <br />  
+
    a)  We check your committer list to make sure it matches what we have in our database. <br />  
b)  The contribution section to should uniquely identify the component (CVS directory), bug # (description if there is no bug # or if there are multiple bug #s), contributor's name, contribution size (LOC), committer who committed this contribution.  <br />
+
    b)  The contribution section to should uniquely identify the component (CVS directory), bug # (description if there is no bug # or if there are multiple bug #s), contributor's name, contribution size (LOC), committer who committed this contribution.  <br />
c)  In the third party software section, we look for CQ numbers, package names and associated licenses.  Then we check to make sure that all the CQs listed for the move / graduation have been resolved and fixed as approved.  We sometimes end up having quite a bit of feedback with projects on this section, so we've put together another handy [http://wiki.eclipse.org/images/5/57/Project_Graduation_or_Move_v5F.pdf flowchart] that addresses the most common scenarios.
+
    c)  In the third party software section, we look for CQ numbers, package names and associated licenses.  Then we check to make sure that all the CQs listed for the move / graduation have been resolved and fixed as approved.  We sometimes end up having quite a bit of feedback with projects on this section, so we've put together another handy [http://wiki.eclipse.org/images/5/57/Project_Graduation_or_Move_v5F.pdf flowchart] that addresses the most common scenarios.

Revision as of 15:13, 6 March 2009

More stuff you wanted to know about IP but were afraid to ask

1. What does the IP Team look for when reviewing code attached to CQs?

In addition to amusing comments from the authors of the code, we look for these kinds of things.


2. Why are committers asked to enter one CQ per jar file?

Using examples, a long-winded answer to that age-old question.


3. To enter a CQ for third party package, or not to enter one.........that is the question.

Maybe a handy flowchart will help (we like flowcharts :-)).


4. My project is going to Move or Graduate. I know it's recommended that I create an automated IP log from here, or if for some funky reason that isn't working, I can create it manually based on this template. What does the IP Team look for when reviewing the IP log?

Well, we look at a few things so it may be a good idea to parse it out.

    a)  We check your committer list to make sure it matches what we have in our database. 
b) The contribution section to should uniquely identify the component (CVS directory), bug # (description if there is no bug # or if there are multiple bug #s), contributor's name, contribution size (LOC), committer who committed this contribution.
c) In the third party software section, we look for CQ numbers, package names and associated licenses. Then we check to make sure that all the CQs listed for the move / graduation have been resolved and fixed as approved. We sometimes end up having quite a bit of feedback with projects on this section, so we've put together another handy flowchart that addresses the most common scenarios.