[ODFPlugtest] Tracking implementation defects

[Jan Wildeboer]

I guess we are moving towards the CERT model I which I think is a very good 
thing.

"Interoperability defect reports" - IDR. A central database of issues, 
affected implementations, defined numbering that allow implementors to state 
that patch #125 fixes IDR 255.

Jan
-- 
Jan H Wildeboer          |
EMEA Open Source Affairs | Office: +49 (0)89 205071-207
Red Hat GmbH             | Mobile: +49 (0)174 33 23 249
Otto-Hahn-Str.20         | Fax:    +49 (0)89 205071-111
D-85609 Dornach/Munich   | eMail:  jan.wildeboer at redhat.com
_____________________________________________________________________

Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane,Charlie Peters,Michael Cunningham,
Charles Cachera
_____________________________________________________________________


----- Original Message -----
From: plugtest-bounces at opendocsociety.org 
<plugtest-bounces at opendocsociety.org>
To: ODF Plugfest mailinglist <plugtest at opendocsociety.org>
Sent: Tue Jun 30 12:53:45 2009
Subject: Re: [ODFPlugtest] Tracking implementation defects

plugtest-bounces at opendocsociety.org wrote on 06/30/2009 12:08:12 PM:


>
> Indeed, although currently you can click on the "backlinks" link in
> the implementation to see what scenario has open issues for that
> implementation.
>

OK.  I did not notice this "backlinks" link.  I think that gives me what I
need.

> Another reason (one I've also mentioned in the FAQ), is that I'm
> expecting people to report these issues to the projects/vendors so
> they can enter it in _their_ bug track system or knowledge base...
>

It would still be good to have a centralized list of these defects,
perhaps with links to the underlying vendor report, if that is available
online.  But in some cases, reporting defects to the vendor is rather
difficult.  For example, do you realize how many layers of internal help
desktop support I would need to go through within IBM before any issue
would be submitted to Microsoft?  It is crazy.  And even if I was able to
do this, the defect report would not be visible to anyone else.  So having
this information mirrored on the wiki is useful.

> Far from perfect of course, although I'm inclined to think that at
> this point more tools (wiki and bugtrack...) aren't the answer :-)
>

With the wiki backlinks support we're probably OK for dealing with 50 or
so scenarios and 200 or so defects.  But I'm not sure it will scale much
beyond that. Not performance-wise, but in terms of support for things like
searching, sorting, filtering, etc., needed to deal with larger data sets.
 But we are probably OK for now.

-Rob

> In a perfect world, I'd want to have both an issue list underneath
> the scenarios (because finding an issue in one implementation may
> lead to finding an issues in another) and the implementations.
>
> But Perhaps there's a bugtrack plugin for DokuWiki that can do just that
?
>
>
> Bart
>
> -----Original Message-----
> From: plugtest-bounces at opendocsociety.org [mailto:plugtest-
> bounces at opendocsociety.org] On Behalf Of robert_weir at us.ibm.com
> Sent: dinsdag 30 juni 2009 17:54
> To: plugtest at opendocsociety.org
> Subject: [ODFPlugtest] Tracking implementation defects
>
> I think it would be good if we entered implementation-defects on the
> implementation page.  That would make it easier to find for an
> implementors since they would not need to load every single scenario
page
> to look for an issue.
>
> For example, I entered some items on Google Docs here:
> http://plugtest.opendocsociety.org/doku.php?id=implementations:gdocs
>
> Note that this is still laborious since we end up transcribing info from

> the scenario page to the implementation page.  A better alternative
might
> be to use JIRA or Bugzilla for defect tracking, since that would give us

> easier reporting support, and tracking of comments and even voting.
>
> -Rob
>
>
> _______________________________________________
> Plugtest mailing list
> Plugtest at opendocsociety.org
> http://lists.opendocsociety.org/mailman/listinfo/plugtest
> _______________________________________________
> Plugtest mailing list
> Plugtest at opendocsociety.org
> http://lists.opendocsociety.org/mailman/listinfo/plugtest

_______________________________________________
Plugtest mailing list
Plugtest at opendocsociety.org
http://lists.opendocsociety.org/mailman/listinfo/plugtest