[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.
So:
* 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 ...)
--MiKu
More information about the cgl_discussion
mailing list