From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suvayu Ali Subject: Re: Org mode issue tracker Date: Thu, 26 Sep 2013 14:13:19 +0200 Message-ID: <20130926121319.GE12411@kuru.dyndns-at-home.com> References: <86ioxp2vbb.fsf@somewhere.org> <20130925080403.GS12411@kuru.dyndns-at-home.com> <86siwt1d9c.fsf@somewhere.org> <8738otjkdt.fsf@gmx.de> <871u4czq4t.fsf@gmx.de> <20130926002156.GA13887@kuru.dyndns-at-home.com> <86vc1of3cp.fsf@somewhere.org> <87eh8ckjtk.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPARm-0004Sr-Hm for emacs-orgmode@gnu.org; Thu, 26 Sep 2013 08:13:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPARh-0005kV-Bu for emacs-orgmode@gnu.org; Thu, 26 Sep 2013 08:13:30 -0400 Received: from mail-ea0-x22d.google.com ([2a00:1450:4013:c01::22d]:42200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPARh-0005kQ-0l for emacs-orgmode@gnu.org; Thu, 26 Sep 2013 08:13:25 -0400 Received: by mail-ea0-f173.google.com with SMTP id g10so504567eak.4 for ; Thu, 26 Sep 2013 05:13:24 -0700 (PDT) Content-Disposition: inline In-Reply-To: <87eh8ckjtk.fsf@gmx.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hello Michael, On Thu, Sep 26, 2013 at 11:34:31AM +0200, Michael Albinus wrote: > > "Sebastien Vauban" > writes: > > >>> ((source . "unknown") > >>> (found_versions "24.3") > >> > >> Emacs version ends up as a tag: > >> > >> * TODO ..... :24.3: > > found_versions is optional. So we cannot assume it is always > set. Furthermore, it is a *list* of strings (although I haven't seen > ever more than one entry). What to do in this case? Indeed, I guess this is quite common. I would think handling this as an optional tag should suffice. > >>> (severity . "normal") > > I would really appreciate, if we could make the severity visible. In the > org manual, I've read something about A B C priorities. On debbugs, we > have the severities "serious", "important", "normal", "minor", > "wishlist", and "tagged". How could we map them on the TODO items? In > debbugs-gnu we use different faces (colors) for the entries. You are right! The default set of priorities are: A, B, and C. But it can be extended; see (info "(org) Priorities"). > > >>> (subject . "24.3; org-crypt: Making epg-context local to *epg* while let-bound!") > >> > >> * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: > >> :PROPERTIES: > >> :DEBGUGS_ID: 15081 > >> :GMANE_URL: > >> http://mid.gmane.org/877gfqkm9t.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > >> :END: > >> <2013-08-13 Tue> > >> > >> As you see above, it would be great if we could simplify the suject and > >> tag the org-module involved (note hyphens are not allowed, they need to > >> be transformed to underscore). > > OK. However, we cannot assume a given syntax on the subject. An error > can be reported by a simple mail to @debbugs.gnu.org, with free > subject. A preformatted subject can be assumed only, if the error has > been reported by `report-emacs-bug' or `org-submit-bug-report'. Would it be possible to have some heuristics? If reported by report-emacs-bug or org-submit-bug-report, try to extract those tags from the subject, otherwise ignore them. > >>> (pending . "pending") > >> > >> And this should finally decide the TODO state. For the moment a > >> reasonable mapping would be "pending" -> "TODO". But would be good to > >> have support for "DONE", "WIP", or similar (I'm not familiar with all > >> the debbug states :-p) > > The pending field could have the values "pending", "forwarded" or > "done". "forwarded" does not seem to be used on debbugs.gnu.org. > >>> (tags) > > Tags are useful for more information on the status. They are a list of > strings like "fixed", "notabug", "wontfix", "unreproducible", > "moreinfo" or "patch". In the given example, this list is empty. I have a suggestion to combine the above two. Assuming we can't have multiple tags from debbugs, something like below should work. - "pending" with no tags -> "TODO" - "done" with no tags -> "DONE" - I can see the use of "unreproducible", "moreinfo", or "patch" tags with "pending" -> "UNREPRODUCIBLE", "MOREINFO", or "PATCH" - Whereas the other tags, "fixed", "notabug", "wontfix", goes with "done". We can map them to: "DONE", "NOTABUG", "WONTFIX". As you see, I treat "fixed" the same as "done" with no tags. This can be implemented by "type" TODO keywords. You basically have 2 states, TODO and DONE. But there are different kinds of them. (setq org-todo-keywords '((type "TODO(t)" "UNREPRODUCIBLE(u)" "MOREINFO(m)" "PATCH(p)" "|" "DONE(d)" "NOTABUG(n)" "WONTFIX(w)"))) Here I'm a bit uncertain about the syntax. Are multiple "DONE" type keywords allowed? If not we could split this into sets as follows: (setq org-todo-keywords '((type "TODO(t)" "UNREPRODUCIBLE(u)" "MOREINFO(m)" "PATCH(p)" "|" "DONE(d)") (sequence "|" "NOTABUG(n)") (sequence "|" "WONTFIX(w)"))) WDYT? > >>> (package "emacs" "org-mode") > >> > >> I guess this is how you filter out org-mode bugs from the rest. > > Yep. In the org-mode case, it is sufficient to filter for the package > "org-mode". But why not create a todo list for another debbugs project, > like "emacs" or "gnus" or whatever? And btw, one could filter also for > other attributes but just package. Even full text search is possible. Great idea, there could be a defcustom where you assign different org files for different package tags! > >> * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: > >> :PROPERTIES: > >> :DEBGUGS_ID: 15081 > >> :REPORTER: Thierry Volpiatto > >> :GMANE_URL: http://mid.gmane.org/877gfqkm9t.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > >> :END: > > Yep. > > Now it comes to the attached emails. In a second (!) step, debbugs-gnu > is able to retrieve the corresponding emails. In the given example, it > would call (debbugs-get-bug-log 15081) This returns a list like > > (((body . "The body of the message") > (msg_num . 5) > (attachments) > (header . "All header lines of the message"))) > > I have just shown one message, of course all messages will be > retrieved. Alternative, one could retrieve the messages in MBOX format. > > Wouldn't it be nice, if we could include the messages as well? Likely > not by default (it would be expensive to download all messages for, > let's say, 500 bugs at once). But we could add a kind of link which, > when followed, could show the messages as well in org-mode. Somehow. Since this is possibile, I think my suggestion about GMANE_URL is redundant. Dealing with this much more detailed information is a matter of taste I think. For example, some like their TODOs to be clean and simple, with all the details in headline attachments. Others might like all the information easily available under the headline formatted as Org text (text as plain text, email attachments as links). I think this requires input from the community. For now as a safe default you could have each message as a sub-heading of the TODO. * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto :END: ** Message 1, From: sender1 Text [[file:email_attachment]] ** Message 2, From: sender2 Text [[file:email_attachment]] Cheers, :) -- Suvayu Open source is the future. It sets us free.