[cgl_discussion] Re: [cgl_tech_board] [CGLE 1.0] Release Coordination Meeting Minutes - 9/19/02

Mika Kukkonen mika at osdl.org
Mon Sep 23 11:11:58 PDT 2002

On Fri, 2002-09-20 at 15:32, Peddibhotla, Rammohan wrote:
> CGLE 1.0 Release Coordination Meeting Minutes- 9/19/02
> ==========================================
>    * Agreed that LTT should be considered part of Dprobes deliverable. 
>      Lisa to confirm that Dprobes maintainer (Vamsi Krishna) can take on 
>      LTT as well. 
>    * Since no current implementation is available for req 5.5 and 5.6 and
> since
>       these requirements are priority 2, they will be dropped from CGLE 1.0
>       implementation.

So you basically moved LTT as a separate feature to be included under
dprobes?? Jeez....

I am having kind of hard time with this thing. Basically the original
reason to that is from the beginning, when we added "tools" to the
architecture in charter, we did it without giving it much of thought
(well, we only discussed the kernel debugger).

Now I have several problems with current situation:
  1) kdb, dprobes and LTT all seem to have non-existent chance to get 
     into mainline, which gives OSDL severe headache
  2) In case of dprobes and LTT, they really are debugging tools that
     you definitely do not want to be active "on-site", so including
     them as part of our "lump of code" (CGLE to all you heretics out
     there ;-) feels little ... silly. Note that this is not the case
     with kdb, where we are adding the password checking just to enable
     it to be live in on-site delivery.
  3) Process-wise, I am very much against this kind of "let's slip 
     feature x 'in', so that when implementation for it is chosen, we
     can get feature y also 'in', because implementation of x requires  
     it" happening.

 * I am going to have a talk with steering group about our charter 
   and role of tools in it. I am _not_ going to request for tools
   to be dropped, but rather to make them understand the issue.
 * Based on steering group reactions, I think there will be some
   kind of separation of tools and the actual CGLE core. What that
   means is still open in my mind; proposals welcome.

>    * The following development tasks have open issues that are expected to
>       be resolved by the PoC by next week:
>         - Hot device identiy: Need to finalize scope of the project. We
>           would need to make an exception for this project to be checked
>           in after 10/4.

This request for "exception" is going to get denied by me, not because I
like being difficult (although I do ;-), but because I do not see a
plausible implementation available that could be done in such a short
development time. All this adds up is that this feature needs to be
postponed to version 2. I'll take it up in tomorrow's TB con call.

>         - Watchdog timer: Which implementation to use

>From what I read from the email discussions, somebody (the project
maintainer?) had defined the requirements so stringent that only one
one card in existence matches it. To me this sounds like a problem in
requirements, not in available set of cards. Action TBD in Spec-sg
meeting (Peter, yet another AR for you ...)


More information about the cgl_discussion mailing list