Skip to Content.
Sympa Menu

cacert-devel - AW: States at bugs.cacert.org

Subject: CAcert Code Development list.

List archive

AW: States at bugs.cacert.org


Chronological Thread 
  • From: <ulrich AT cacert.org>
  • To: <cacert-devel AT lists.cacert.org>
  • Subject: AW: States at bugs.cacert.org
  • Date: Mon, 20 Jun 2011 02:47:12 +0200
  • Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none
  • Importance: Normal

Hi,

1. incorporate the bugs states in the
   https://wiki.cacert.org/Software/Assessment/Documentation
   Software Update Cycle procedure
   at which step which role has to change the bugs report
   to which state
-and-
2. write the full documentation for bugs with detailed descriptions
   under 
   eg  https://wiki.cacert.org/Software/Assessment/Documentation/bugs



regards, uli   ;-)


-----Ursprüngliche Nachricht-----
Von: Bernhard Fröhlich 
[mailto:bernhard AT cacert.org]
 
Gesendet: Samstag, 18. Juni 2011 19:44
An: 
cacert-devel AT lists.cacert.org
Betreff: Re: States at bugs.cacert.org


Am 14.06.2011 04:06, schrieb Michael Tänzer: 
Hi Folks,

On 14.06.2011 00:59, Michael Tänzer wrote:
  
Upcoming changes: introducing new bug states to reflect our Software
Assessment process ("needs work", "needs review & testing", "needs
testing", "needs review", "ready to deploy")
    
Those new states are now introduced and hopefully already working as
expected. Prepare for a colourful experience when opening the bug
tracker (ultra nerds might want to consider to get some sun glasses just
in case ;-).

There are also two filters prepared "Needing Testing" and "Needing
Review" which you can also subscribe to in your feed reader to get
updates. Yay.
  

BTW, can we write down somewhere the exact meaning of the states? 
I'm not so much thinking about the new states which are quite clear, but
more the implication of the standard states:

When should a bug be switched to confirmed? Is this when development team
agrees that it is a bug? Or if someone could reproduce it? Or work has
been started? 
When to close a bug? If everything's said and done? If a fix is installed
(I guess that state is now "solved?")? If the reporter is content? If the
bug remained x weeks in "solved?" status? 
I'd propose the following:

A bug is "confirmed" when someone of development team can confirm that the
bug exists, so ideally s/he could reproduce or witness the bug at least
once. 

A bug is usually closed by the reporter (or better: if the reporter
confirms the solution) and nothing else, like a pending Arbitration, is
open about the bug. If a bug is in "solved?" status for 8 weeks and
nothing else is known it may be closed by someone involved in fixing the
bug (development or testing).

How does this sound?
Ted
;)

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.16.

Top of Page