harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Beliaev" <vladimir.k.beli...@gmail.com>
Subject [drlvm][jira] defining platform in Environment & use [module] in summary.
Date Fri, 27 Apr 2007 14:37:16 GMT
Hello, All,

I'm tracking Harmony status on Windows/x86_64 platform which was recently
enabled (there were 55 JIRAs fixed for DRLVM & CLASSLIB).

During this process I've found out that we have a pretty ... h-m-m...
democracy way of describing DRLVM JIRAs in terms of providing issue platform
(what platform the issue is reproducible on):
- sometimes people use a platform abbreviation in JIRA summary (like
[drlvm][winx64])
- sometimes people provide a platform description in "Environment" field of
JIRA

The same is true for "buggy modules" definition (in JIRA summary after
[drlvm] prefix) - currently you may see in JIRA the modules like [thread],
[threading], [jit], [opt], [jet] + a lot of other non-"VM module" names like
[smoke], [EUT], [smoke tests], [reliability]...

This makes a navigating through JIRA a bit complicated for me. In particular
the http://wiki.apache.org/harmony/Unresolved_Bugs_History document shows a
pretty structured statistics for CLASSLIB (for JIRA by modules distribution)
still it shows something ... h-m-m... medley-like for DRLVM.

Ok, I'd like to get it beautified a bit for DRLVM (with the help of
committers of course)...

The following rules are to be used for this:

1. the affected platform is to be defined in "Environment" field of JIRA.
One should not use a platform identification as JIRA summary prefix like
[drlvm][winx64].

2. to enable search by platform the fixed names is to be used in
"<arch>/<os>" format like:
      x86/WinXP
      x86_64/SLES9
      any

3. the [module name abbreviation] is to follow by [drlvm] prefix. Only the
known abbreviation are allowed - they can be taken from working_vm/vm
directories structures (with some correction) to avoid bicycle inventing.
They are: em, gc_cc (or gcv4.1), gc_gen (or gcv5), gcv4, port, thread, vmi,
vmstart, classloader, exception, init, interpreter, jit, jni, jvmti, kernel,
object, reflection, stack, util, verifier.

4. there are three special "modules" - [doc] for documentation JIRAs,
[build] for build related issues and [test] for bugs in drlvm tests.

5. if the known module name is omitted then the bug is considered as
"unclassified" (http://wiki.apache.org/harmony/Unresolved_Bugs_History
recognizes
such bugs)

6. finally, the next prefix (after [drlvm][module]) is allowed (it is
optional). For example, it may specify affected workload/characteristic like
[EUT] for the bug found by EUT or [reliability] for the reilability issues.

I know the solution is not perfect still I want to get it implemented if
nobody objects.

Thanks
-- 
Vladimir Beliaev
Intel ESSD

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message