Release QA Tracking Tool

I'm going to write, under guidance from André Schnabel, a
new Release QA
Tracking Tool that will, among other things, replace the
current "Status
page for Localized builds" at
http:/
/qa.openoffice.org/localized/status.html

The basic idea is to have clear, informative and attractive
screens for
the general public, easy management and updating, IssueZilla
integration, notification by e-mail and RSS feeds and easy
extensibility.

The target audience is:
* the general public, that will be able to easily see the
status of
builds in QA
* the Native-Lang teams, that will be able to update the
page,
coordinate through the interface and receive real-time
notification when
builds are added, rejected or approved.

I set up a page in the wiki and I'm soliciting your
comments. The
proposal is the best I could design from my experience in
the Italian QA
team, but I'm open to suggestions.

Once we have some usable code, I will notify this mailing
list again and
give interested teams the opportunity to try the tool.

Please read the whole proposal and details and make comments
at
http://wiki.services.openoffice.org/wiki/Releas
e_QA_Tracking_Tool
(the wiki should be working also during the infrastructure
upgrade of
June 20-22).

Best regards,
  Andrea Pescetti.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

   From: Andrea Pescetti <pescettiopenoffice.org>
   Date: Mon, 19 Jun 2006 23:59:08 +0200

Hi,

   > http://wiki.services.openoffice.org/wiki/Releas
e_QA_Tracking_Tool

I'm writing these comments partially offline, so I'm not
entering them into
Wiki:

- why "*Release* QA Tracking Tool?"

  This tool can be used also for regular QA done on
development milestone
  or other builds as well. Build that are not meant to be
  "released". E.g. m173 includes childworkspace
that affect almost every
  module, thus it is a good target for complete QA.

- "types of users"

  Just to clarify - you are talking about
"roles", right? It is clear from
  the next paragraphs (ADM has all priviledges of BPR and
QAL, ...), but
  ...

- about QAL: there are cases where one user is QAL for more
languages
  (e.g. Rail), please do not forget it.

- "English build -> build providers are
notified"

  The question is when we want BPRs to be notified. I think
they should be
  notified on every milestone, not only on builds provided
by Sun. Sun
  skips some builds. But this is not clear yet.

I think the description is good otherwise. Thanks for it!  
-- 
Pavel Janík

/* Sun, you just can't beat me, you just can't.  Stop
trying, give up.  I'm
serious, I am going to kick the living shit out of you, game
over, lights out.
*/                -- Linux kernel: arch/sparc/lib/checksum.S

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

Pavel Janík wrote:
>    > http://wiki.services.openoffice.org/wiki/Releas
e_QA_Tracking_Tool
> - why "*Release* QA Tracking Tool?"
>   This tool can be used also for regular QA done on
development milestone
>   or other builds as well. Build that are not meant to
be
>   "released".

That's true. Even if it was designed with the release
workflow in mind,
it can be applied to other builds as well. The SVN
repository, in fact,
is called just "qatrack".

> - "types of users"
>   Just to clarify - you are talking about
"roles", right?

Yes, I meant "roles".

> - about QAL: there are cases where one user is QAL for
more languages
>   (e.g. Rail), please do not forget it.

OK. This should not be a problem.

> - "English build -> build providers are
notified"
>   The question is when we want BPRs to be notified. I
think they should be
>   notified on every milestone, not only on builds
provided by Sun. Sun
>   skips some builds.

Interesting; I didn't know about this. So how does it work?
The source
code for "milestone mxxx" is declared frozen and
made available and then
SUN may or may not create builds from it? It this is the
case, we could
just use the "source code frozen" message to
trigger notification to
BPRs. Who decides when the source code is ready for a
milestone build?

Yours,
  Andrea.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org

Hi Andrea,


Andrea Pescetti schrieb:
> ...I set up a page in the wiki and I'm soliciting your
comments. The
> proposal is the best I could design from my experience
in the Italian QA
> team, but I'm open to suggestions.
>
> Once we have some usable code, I will notify this
mailing list again and
> give interested teams the opportunity to try the tool.
>
> Please read the whole proposal and details and make
comments at
> http://wiki.services.openoffice.org/wiki/Releas
e_QA_Tracking_Tool
> (the wiki should be working also during the
infrastructure upgrade of
> June 20-22).
>   

Thanks for the wiki, I left some comments there.

Tha main problem to me is the setup of a initial matrix for
a relase / 
RC, that's why I had the idea to automate the listing of
new builds 
somehow. For identifying the platform / OS, there should be
some pattern 
matching algorithm, that needs to be configurable within the
tool. Hope, 
we can implement something like that.

André

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeqa.openoffice.org
For additional commands, e-mail: dev-helpqa.openoffice.org