All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: yocto@yoctoproject.org
Subject: Re: Bugzilla Changes
Date: Mon, 01 Nov 2010 16:42:05 -0700	[thread overview]
Message-ID: <4CCF504D.6050902@linux.intel.com> (raw)
In-Reply-To: <4CCF33E1.6080600@windriver.com>

On 11/01/2010 02:40 PM, Bruce Ashfield wrote:
> On 10-11-01 4:13 PM, Saul Wold wrote:
>> On 11/01/2010 12:17 PM, Darren Hart wrote:
>>> On 10/30/2010 01:50 AM, Saul Wold wrote:
>>>>
>>>> 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
>>>> Bugzilla
>>>> categorization.
>>>>
>>>> Currently we have "Core OS" with the following Components:
>>>> General
>>>> Graphics Driver
>>>> Kernel
>>>> Tool Chain
>>>>
>>>> Along with "Poky" which contains:
>>>> General
>>>> SDK Tools
>>>>
>>>> There are also product categories for "Runtime Distribution", "Sato"
>>>> and
>>>> "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
>>>
>>> The divide between User Space and Tool Chain is a bit vague. For
>>> instance, I would generally expect to see glibc under User Space, but
>>> your description seems to place it under Tool Chain.
>>>
>> Good point. (See my reply to Mark's email)
>>
>>> > and general Kernel - Break it down to Arch / Config components
>>>
>>> Please keep the kernel separate from the Tool Chain, something along the
>>> lines of:
>>>
>>> Kernel
>>> - Core
>>> - Drivers
>>> - Tooling (Trace, Debug, Perf)
>>>
>> I think my lines might have run together! It was meant to be separate,
>> and this looks like a good break down.
>
> This is too much separation, having over categorization
> of the kernel defects at this point is overkill.

Agree in principle.

> I'd suggest three categories:
>
> - kernel build (which often transitions to
> straight up build-system after triage).
> - kernel configuration
> - kernel runtime

Let me confirm:

- kernel runtime (this includes all errors, panics, BUGs, etc. from the
   three categories I listed above - no objection).

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 
"not-a-distribution".

> Let's keep it simple.

Agreed.

-- 
Darren Hart
Embedded Linux Kernel


  reply	other threads:[~2010-11-01 23:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-30  8:50 Bugzilla Changes Saul Wold
2010-11-01 16:50 ` Xu, Jiajun
2010-11-01 19:00 ` Mark Hatle
2010-11-01 20:25   ` Saul Wold
2010-11-01 19:17 ` Darren Hart
2010-11-01 19:43   ` Mark Hatle
2010-11-01 20:13   ` Saul Wold
2010-11-01 21:40     ` Bruce Ashfield
2010-11-01 23:42       ` Darren Hart [this message]
2010-11-02 19:13         ` Bruce Ashfield
2010-11-01 19:56 ` Foster, Dawn M

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CCF504D.6050902@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=bruce.ashfield@windriver.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.