In an attempt to better organize bugzilla (see my p.s. if you're asking
"what about phabricator?"), I'd like to propose the following changes to
how we track and monitor bugs.
First, how we use status. Using 'VERIFIED' is new, and allows us to
resolve all the bugs that we're just waiting on:
Bugzilla supports the following statuses. This is how they're used in
UNCONFIRMED - New bugs, not yet assigned.
CONFIRMED - Assigned for triaging to determine root cause, and
IN_PROGRESS - Root cause has been identified and being worked on.
RESOLVED - Root cause fixed. i.e. patch sent
VERIFIED - Fix has been accepted, backported as necessary, and
test can be removed from skiplist/known issues list.
To implement this, we'd need to set all of the LKFT bugs that are
already RESOLVED to VERIFIED. There are 200, and it can be done in one
fell swoop in bugzilla (multi bug change). Then, we'll have to regularly
review the list of RESOLVED (but not VERIFIED) bugs for their status,
and re-open or verify as necessary.
Second, how we use Component. Our components can be one of LTP, Kernel,
kselftest, or General. Right now, we search for e.g. kernel bugs using
the 'kernel' keyword, but we apply the kernel keyword for anything that
needs to be updated in the kernel tree (including kselftest changes). If
we filter using component instead, we can more easily find our actual
kernel bugs, vs things in kselftest or ltp. Things in none of those are
Keywords can then be used to be more granular than component, but are
often not necessary and I've always found their usage a tad confusing.
They can be treated as optional.
Lastly, priority. I don't think we're really good about setting
priority, but I'd like to go through and set priority based on the
- First, actual kernel bugs.
- Second, by impact. Things that impact all boards and all branches are
a higher priority than a single board/branch combination.
- Third, by triviality. Fix the easy ones first.
- Last, things that are difficult and small in terms of impact.
The criteria is a guideline and is flexible/subject to reason. An actual
kernel bug in x86 that is very minor may be lower priority than a build
problem that is causing instability in our environment.
Once we agree, I'll update
https://collaborate.linaro.org/display/EP/Bugs with this information and
go through all the bugs and apply these rules accordingly.
The 'bug lists' listed on that page will change to:
- All bugs, sorted by priority
- Bugs by component:
- Kernel bugs, sorted by priority
- LTP bugs, sorted by priority
- Kselftest bugs, sorted by priority
- General bugs, sorted by priority
- Bugs by status:
- New bugs (unconfirmed)
- Confirmed bugs
- In progress bugs
- Resolved (but not verified) bugs
p.s. apologies for the mixed signals with regard to using bugzilla vs
phabricator vs refactoring how we use bugzilla. I've grown frustrated
and need to do _something_ asap, and it's not clear to me what the
future holds. This is something we can do immediately.