Package: bugs.debian.org Severity: normal Some time after a ticket is closed, it is "archived". One useful effect of archival is that archived ticket are filtered by default when listing a package's tickets. The user can list archived tickets, unarchived tickets, or both.
Archival causes multiple bugs, many of which are reported. I hit one more when replying to a message which had closed a ticket, as can be seen below. Thankfully, the ITS sends an error message which hints that archival may be the problem (as was the case in my reply below), so the problem can be noticed, and worked around by ordering the ITS to unarchive the ticket, as explained in http://www.debian.org/Bugs/server-control#unarchive It is not entirely clear how archival works and why it happens. The only benefit I can see is to act as a filter for no longer relevant tickets. This advantage could easily be substituted by adding a filter on the ticket's status which could be tuned to disregard closures in the last x days, although the good solution would be to list all tickets affecting a given set of versions. Ticket archival was implemented at a time where resources were quite limited, to replace... pure ticket deletion: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=9705 If there are no other advantages, I guess archival is no longer a good strategy and should simply be eliminated. One corner case to consider is tickets against pseudo-packages (no versions). Otherwise, we should simply accept mail to archived tickets. -------- Original Message -------- Subject: Delivery Status Notification (Failure) Date: Mon, 03 Jun 2013 03:33:17 +0000 From: Mail Delivery Subsystem <[email protected]> To: [email protected] Delivery to the following recipient failed permanently: [email protected] Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the server for the recipient domain bugs.debian.org by buxtehude.debian.org. [140.211.166.26]. The error that the other server returned was: 550 Unknown or archived bug ----- Original message ----- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=03LNJfa0V+QgcjejBaBoF5yYSse5tT3vhUMOlaFlVII=; b=V9ndLMNVBv9y3J8VV59F7nsVgfPGPMm1qcZBEOUzs06Zx6gRXZBqAUpF+W8vPrflbE pC/YNXpNhaSa+EQ3YA2VghZQLItDm3jcL6uaNGd3Y3YD/98mS5wu0hixIlmlwl5DUyfj Z1zd95EYtTF1wROzp3FkvvP8qtyRyQ+iIjB5LkCqrFC/2tufk/XrAmfj32IN58k9QtUC BdlTYNIJMbFjxH8h5SR/qyU4pFl16VbpZ1ZQDtiPw7Fi7Ni2p8nMR5Ck1Vzhd3i1GkRj vdr6sqg9HN7MoLqHWL/BI4MQf0HW+g1KFFTrhmvJVaSLRk2qXrjw9Bfe1EXx2RUrKf+k Oz4A== X-Received: by 10.49.87.106 with SMTP id w10mr19453210qez.36.1370230390290; Sun, 02 Jun 2013 20:33:10 -0700 (PDT) Return-Path:<[email protected]> Received: from [192.168.1.103] (modemcable156.191-56-74.mc.videotron.ca. [74.56.191.156]) by mx.google.com with ESMTPSA id r8sm11998712qaq.11.2013.06.02.20.33.07 for<multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 20:33:09 -0700 (PDT) Message-ID:<[email protected]> Date: Sun, 02 Jun 2013 23:33:30 -0400 From: Filipus Klutiero<[email protected]> User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Jonathan Nieder<[email protected]>, [email protected] CC: [email protected] Subject: Re: [bugs.debian.org] Ticket priorities References:<[email protected]> <[email protected]> In-Reply-To:<[email protected]> Content-Type: multipart/alternative; boundary="------------030105010007000703060509" reopen 704874 thanks Hi Jonathan, On 2013-04-07 18:11, Jonathan Nieder wrote:
Hi, Filipus Klutiero wrote:Currently, all wishlist tickets show together, without any distinction according to costs or benefits.I think splitting up bugs according to one's personal priorities can be a valuable thing when the bookkeeping is not too much trouble. The main problem with using a shared field for that is that different people and organizations can have different priorities.
Indeed. Importance is definitely not the same to everyone, even though we currently track it as a shared field. Investment can also be considered as variable if it is considered as the time the viewer would require to address the problem (if I don't know C++, my priority for an issue in a C++ program would be much lower than for a C++ programmer, even if we both consider that the issue has equal importance). As priority is a combination of both, it could be argued that it is even more personal than importance. At least importance and priority should be customizable in an ideal world.
Would usertags work for this purpose for you?
Short answer: no. Long answer: It's possible to make for example a "prioritary" tag, but this would only give a simplistic classification. Priority is relative, so tracking it via boolean flags would be poor. We could achieve a higher accuracy using several tags like unimportant, lowimportance, normalimportance, etc, but this would also be cumbersome (changing priority would mean removing a tag and tagging again, for example). And the reality is that years after the introduction of usertags, I'm not aware of anyone who found them good enough to prioritize issues. There are however 2 tags used for prioritization: patch and wontfix. Tickets tagged patch require an investment much lower than others on average since most of the investment should be past. Conversely, wontfix is used by many developers in the sense of
