[rt-pmc] [CQ 2561] Apache tomcat Version: 6.0.16

[emo-ip-team@xxxxxxxxxxx]

http://dev.eclipse.org/ipzilla/show_bug.cgi?id=2561


thomas menzel <t.menzel@xxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t.menzel@xxxxxxx
           Severity|awaiting_committer          |awaiting_pmc




--- Comment #24 from thomas menzel <t.menzel@xxxxxxx>  2008-10-01 11:47:05 ---
hi barb,

top 1 understanding CQs
--------------------
after reading the comments we (ralf and i) have still further questions, so we
understand the CQ process more fully and bring more light into the subject:
so, pleeaeeasssse bear with us ;) 

our view of the whole CQ idea and reason of entering them is like so:
we have piece of dependency that needs to clear IP-wise for usage. 
since u like to do that automatically over manually u use tools to scan and
check the contributions.
the output of these are among others a list of jars or zips that u see then as
the finest entity on which granting occurs. 
in that sense, this is a bottom-up look-up check, i.e.  i found the jar J in
contribution C. now, do i have that in my CQ library and is it approved?  

this is understandable and then it makes sense (albeit a lot of work) to entery
all CQs on jar-level.

deducing from your and jeff's comments, it makes also sense for the following
rule to safe at least some work.
rule: for jars with common prefix -> one CQ b/c they are not used singly but
always in that group.

Q: are we right then, that we can also apply this rule to the first group of
jars (in sorted order):? 
  annotations-api.jar 
  catalina.jar 
  catalina-ant.jar 
  catalina-ha.jar 
  catalina-tribes.jar 
  jasper.jar 
  jasper-el.jar 
  tomcat-coyote.jar 
  tomcat-juli.jar 

in the sense, that this makes then 4 CQs?
should we also name these CQs then tomcat-*.jar and catalina.*jar or smth.
alike to denote their umbrella character?

ur instructions for the next dependencies puzzles us though and doesnt quite
fit into our view explained above, namely, to enter a CQ for each source-zip
from which only one jar built.
in the end it is just a matter of definition where u say: "ok, as of this level
in the source tree these are separate projects and hence CQs." and that, if i
may, seems to be very arbitrary.
or is it here the case that we have 3 zips that are downloaded seperatly during
the build and in case it would have been only one download (i.e. someone felt
the need to just distribute the sources packaged differently for what every
reason) it would have been only one CQ?

on the other hand, it might also be valid for the CQ process to say: we handle
the matter of dependencies always on the finest level available. 
hence, if i have one jar from several sources, then the sources are the finer
level. 
if i produce several jars from one big glob of sources, then we base the CQs on
the jars. 
the rational behind this, could be, to say: "we need to be on the safe side
when doing CQs and that way nothing slips through our hands. and yes it is more
work, but we are for that on the safe side."

well, so much for ur patiece with us on this.
we could have just entered the CQs as u directed but we would have been left
ignorant -- and that is never a good thing ;)

top 2 latest version
--------------------
it is no problem for us to switch to the latst version for the benefit of all
and will do so when we do the depending CQs. 
at the time this tomcat version was integrated into our project it was the
latest version -- time flies. 



-- 
Configure CQmail: http://dev.eclipse.org/ipzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the CQ.