[drlvm][jira] defining platform in Environment & use [module] in summary.

[Vladimir Beliaev <vl...@gmail.com>]

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

Re: [drlvm][jira] defining platform in Environment & use [module] in summary.

[Vladimir Beliaev <vl...@gmail.com>]

Gregory (thanks a lot!!!) & I went through DRLVM JIRAs using the rules below
& updated summary. There are couple points to take a look at & respond:

- we added 4 new "modules" which do not correspond to any drlvm directory
(see my origimal e-mail please). They are:
  helpers
  logger
  shutdown
  finalization

- let's get changed
http://wiki.apache.org/harmony/Unresolved_Bugs_Historyto provide
expanded information about drlvm issues:


–         *Unresolved DRLVM issues by module* chart should recognize the
predefined modules names only which are:
em, gc, 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, helpers, logger, shutdown,
finalization. The test, doc & build issues must not be counted at all,
unspecified/unrecognized module issue should got to "unspecified module"
category in this chart.



–         One more chart to be added – *Unresolved DRLVM build/doc/test
issues* – it shows DRLVM doc, test & build issues distribution (looks the
same to *Unresolved DRLVM issues by module*)



–         One more chart to be added – *Unresolved DRLVM issues by impact* –
this chart distributes all of the issues (regardless some issues are already
in first two charts) – first [<word>] is summary considered as an impact if
it is not a [drlvm] or predefined module name (including build/doc/test).
Ideally will see there the classified bugs like:
[drlvm][classloader][EUT] blah-blah-blah
and unclassified bugs also like:
[drlvm][freemind] blah-blah-blah

Thanks
Vladimir Beliaev

2007/4/27, Vladimir Beliaev <vl...@gmail.com>:
>
> 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
>



-- 
Vladimir Beliaev
Intel Middleware Products Division