On 10-11-01 07:42 PM, Darren Hart wrote:
On 11/01/2010 02:40 PM, Bruce Ashfield wrote:
On 10-11-01 4:13 PM, Saul Wold wrote:Agree in principle.
On 11/01/2010 12:17 PM, Darren Hart wrote:This is too much separation, having over categorization
On 10/30/2010 01:50 AM, Saul Wold wrote:Good point. (See my reply to Mark's email)
The divide between User Space and Tool Chain is a bit vague. For
We need to review the existing Bugzilla and update the Products and
Categories to reflect the projects correctly. Please review this email
and make comments, suggestions for moving forward with a better
Currently we have "Core OS" with the following Components:
Along with "Poky" which contains:
There are also product categories for "Runtime Distribution", "Sato"
"SDK Plugins". Along with other infrastructure items.
I would propose that we clearly define the some new products and move
bugs as appropriate:
Poky Build System - for Poky class and configuration issues
User Space - for user space, patching and runtime failures
Tool Chain - break it down to compiler, tools, libraries
instance, I would generally expect to see glibc under User Space, but
your description seems to place it under Tool Chain.
I think my lines might have run together! It was meant to be separate,
and general Kernel - Break it down to Arch / Config componentsPlease keep the kernel separate from the Tool Chain, something along the
- Tooling (Trace, Debug, Perf)
and this looks like a good break down.
of the kernel defects at this point is overkill.
I'd suggest three categories:Let me confirm:
- kernel build (which often transitions to
straight up build-system after triage).
- kernel configuration
- kernel runtime
- kernel runtime (this includes all errors, panics, BUGs, etc. from the
three categories I listed above - no objection).
It does. What we can also do, is split it between
'kernel' and 'BSP'. I've been triaging bugs like this
for 6 years now, and typically it is very hard for
the submitters to categorize properly. But typically
they do know if it is particular to a board (BSP) or
everywhere (kernel). The BSP would also cover the drivers
category that you had listed above .. since often, drivers
are exercised by one (or few) boards and those are the
ones that have problems.
It's still 3 categories, but separate by type of bug instead of area of
bug. It's still fine with me. My biggest concern was keeping the kernel
separate, and it is in either form. I'll happily defer to Bruce with
respect to an efficient set of kernel bug categories for an embedded
Agreed. We are aligned here. We'll adjust these as we
go forward to whatever makes sense.
Let's keep it simple.Agreed.