CGL 5.0 - Git

[florian.heigl@xxxxxxxxx (Florian Heigl)]

Hi Greg,

I cut this mail in short as I just noticed the "gaps" document is still
called a draft
but has a lot more content now than a month ago, so most of my points are
irrelevant now.
It had been a one-item draft so long I stopped looking at it.

About EVLOG, I'll reread the thread, and I think I'll also try to find out
whether IBM
simply killed it offf like EVMS.

>> maybe it would help if the CGL current members pick some person who
>> reevaluates all "useful" patches and then someone should go through
>> them one by one and sort them, and eventually re-submit.
>
> Having the developer who created the patch, and who is going to maintain
> it, is best to do the submission.  Otherwise some other person can't
> answer the questions and queries very well.

I see that, but how to keep track of (for example) projects that die off
somehow,
or like the PPC example are deemed to work "good enough" for some but
no more tries for integration are done? Of maybe this is a moot point when
you don't
define hard requirements anymore. At the least I think that CGL should keep
a certain
awareness of what patches are seeking for approval, and maybe help the
developers
with the "follow up" effort if the  patch is considered important for CGL.
Or does that sound a bad idea?

I still think some more details wouldn't hurt...
one random example from the satisfied requirements.
"AVL.2.1 Multi-bit ECC handling

*Priority: * P3

*Description: * CGL specifies that carrier grade Linux shall provide a panic
trigger mechanism when hardware error checking and correcting (ECC) detects
multi-bit ECC errors."

I think it'd be nicer if there was some added info, i.e. that this might
require dmidecode in userland. Or is there some other document that lets one
read up on how the requirement fullfillment was tested?
but - I just lurk here,
personally thanks a lot for the hint to quilt, I'll give it a try very soon.

Thanks,
florian

-- 
'Sie brauchen sich um Ihre Zukunft keine Gedanken zu machen'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/20080519/bc66f222/attachment.htm