Re: [O] Org mode issue tracker
Brett Viren b...@bnl.gov writes: Hi, Hi Brett, * TODO Subject timestamp :emacs_ver:org_ver:org_module: ... Emacs version ends up as a tag: * TODO . :24.3: Or, if I add an Org version: * TODO . :24.3:8.0.3: These bare numbers seem a bit too anonymous to me. I think it's unlikely that Org will reach versions in the 20's anytime soon so collision won't happen for a while but eventually (hackers willing!) it will. So, I suggest simply qualifying the versions like: * TODO . :emacs_24.3:org_8.0.3: From the metadata retrieved from debbugs.gnu.org, we have just a list of version strings. There is no indication about the meaning: (found_versions 24.3) One could teach people to use also package names but mere version numbers, but that's up to the package maintainer's will. So up to now the strings provided by found_versions will be used as tags, until there's a better rule for matching. I can also see a desire to list other software and their versions that might be implicated in the bug being reported. Listing their bare versions as tags is, I think, obviously no good. They could just include this info in an ad-hoc manner in the body of their report, but maybe it would be good to define a property to explicitly list them following the same package_version pattern of the tags. * TODO . :emacs_24.3:org_8.0.3: :PROPERTIES: :IMPLICATED_SOFTWARE: texlive_2012.20120611-5 beamer_3.10-2 The debbugs server returns also a list like (found (item (key . 24.3) (value))) Maybe this could go the direction we want. Obviously, in this example key should be Emacs, and value should be 24.3. Then we might also get something like (if set properly by submitter or maintainer) (found (item (key . emacs) (value . 24.3)) (item (key . org) (value . 8.0.3))) The IMPLICATED_SOFTWARE property proposed by you could be derived from the (affects) entry. But I haven't seen ever that somebody uses this attribute. It's always empty, as shown in this example. -Brett. Best regards, Michael.
Re: [O] Org mode issue tracker
Hi Suvayu, What a nice work you've done... Some comments... Suvayu Ali wrote: This is the general structure I'm proposing: * TODO Subject timestamp :emacs_ver:org_ver:org_module: :PROPERTIES: :DEBGUGS_ID: bug number :REPORTER:Reporter Name :CC_EMAIL:list of emails of interested parties :END: I elaborate the ideas below. On Wed, Sep 25, 2013 at 08:56:50PM +0200, Michael Albinus wrote: Let's check it with an example. For bug 15081, debbugs-gnu returns the following list: ((source . unknown) (found_versions 24.3) Emacs version ends up as a tag: * TODO . :24.3: (done) (blocks) (date . 1376383861) * TODO . :24.3: 2013-08-13 Tue I'd use the inactive version of the timestamp, that is (for Michael) [2013-08-13 Tue]. (fixed) (fixed_versions) (mergedwith) (found (item (key . 24.3) (value))) (unarchived) (blockedby) (keywords) (summary) (msgid . 877gfqkm9t@gmail.com) An added bonus idea: Gmane has this amazing feature where you can link to a message using it's message id. So a property like: GMANE_URL would be awesome. * TODO . :24.3: :PROPERTIES: :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 2013-08-13 Tue (id . 15081) * TODO . :24.3: :PROPERTIES: :DEBGUGS_ID: 15081 :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 2013-08-13 Tue It would be cool if you could provide a function that uses browse-url to direct you to the webpage using DEBGUGS_ID: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15081 We could get it by adding a new link type, don't we? (forwarded) (severity . normal) (owner) (log_modified . 1376383862) (location . db-h) (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@gmail.com :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). (originator . Thierry Volpiatto thierry.volpia...@gmail.com) * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto thierry.volpia...@gmail.com I'd maybe use Creator or CreatedBy (with or without hyphens or underscore) to make that framework less bug-specific. That way, I guess it could stay as well as general for common tasks in any project. BTW, is there a convention for using ALLCAPS or First-letter-cap? I mean: the time estimate property is written Effort, not EFFORT; is there a convention to distinguish between Org official built-in properties, and user-defined ones? Or is there another rule? (This question may sound stupid, but I live conventions, so that all files look the same). :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 2013-08-13 Tue (last_modified . 1376408720) Maybe this should go into a property called: LAST_MODIFIED. (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) (affects) (archived) (tags) (package emacs org-mode) I guess this is how you filter out org-mode bugs from the rest. (fixed_date) (found_date) (bug_num . 15081)) The keys shall be self-explaining. How would a TODO item look like? Note, that these metadata do not contain the corresponding messages yet. debbugs-gnu could retrieve them in a second run; the TODO item shall offer a link to them, inline. So finally I propose the following for this particular bug. * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto thierry.volpia...@gmail.com :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 152 2013-08-13 Tue What's this 152? A typo? However in this example there were no interested parties. If you take this (non org-mode) bug as an example: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15282, the CC_EMAIL property would be: Eli Zaretskii e...@gnu.org, Gregor Zattler telegr...@gmx.net, hyper...@debian.org, Paul Eggert egg...@cs.ucla.edu, and all the contributors to bug 15222 (that would be me :-p, Suvayu Ali fatkasuvayu+li...@gmail.com). What do others think? Is it a good start? I like your work a lot! Overall this looks very promising, I am excited :). So do I. Best
Re: [O] Org mode issue tracker
Hi Seb and others, On Thu, Sep 26, 2013 at 09:29:10AM +0200, Sebastien Vauban wrote: (date . 1376383861) * TODO . :24.3: 2013-08-13 Tue I'd use the inactive version of the timestamp, that is (for Michael) [2013-08-13 Tue]. Doesn't the agenda show active timestamps only? Developers working on bugs might want to add the file as their agenda file. It would be cool if you could provide a function that uses browse-url to direct you to the webpage using DEBGUGS_ID: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15081 We could get it by adding a new link type, don't we? Indeed! I usually dislike bare links in documents. I think it breaks the flow of text. Your suggestion sounds perfect! (originator . Thierry Volpiatto thierry.volpia...@gmail.com) * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto thierry.volpia...@gmail.com I'd maybe use Creator or CreatedBy (with or without hyphens or underscore) to make that framework less bug-specific. That way, I guess it could stay as well as general for common tasks in any project. Indeed a great suggestion! BTW, is there a convention for using ALLCAPS or First-letter-cap? I mean: the time estimate property is written Effort, not EFFORT; is there a convention to distinguish between Org official built-in properties, and user-defined ones? Or is there another rule? (This question may sound stupid, but I live conventions, so that all files look the same). I'm not sure if there is any convention. So finally I propose the following for this particular bug. * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto thierry.volpia...@gmail.com :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 152 2013-08-13 Tue What's this 152? A typo? It's a typo. :-p What do others think? Is it a good start? I like your work a lot! Thank you :). -- Suvayu Open source is the future. It sets us free.
Re: [O] Org mode issue tracker
On Thu, Sep 26, 2013 at 10:22 AM, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Thu, Sep 26, 2013 at 09:29:10AM +0200, Sebastien Vauban wrote: BTW, is there a convention for using ALLCAPS or First-letter-cap? I mean: the time estimate property is written Effort, not EFFORT; is there a convention to distinguish between Org official built-in properties, and user-defined ones? Or is there another rule? (This question may sound stupid, but I live conventions, so that all files look the same). I'm not sure if there is any convention. There is: User-defined properties are capitalized, see http://orgmode.org/manual/Conventions.html Although for user-defined properties and at least for my private Org files I don't follow this convention and prefer all lower case. It helps me e. g. when sorting properties with locale C: Built-in properties first, User-defined last. Michael
Re: [O] Org mode issue tracker
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Hi Sebastien and Suvayu, Thanks a lot for your comments. That's pretty good for starting a proof-of-concept. Will do. Some comments from my side: ((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? (msgid . 877gfqkm9t.fsf-re5jqeeqqe8avxtiumw...@public.gmane.org) An added bonus idea: Gmane has this amazing feature where you can link to a message using it's message id. So a property like: GMANE_URL would be awesome. * TODO . :24.3: :PROPERTIES: :GMANE_URL: http://mid.gmane.org/877gfqkm9t.fsf-re5jqeeqqe8avxtiumw...@public.gmane.org :END: 2013-08-13 Tue Agreed. However, debbugs.el is also capable to retrieve all messages from the server, as we do in debbugs-gnu. I'll show below. (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. (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-re5jqeeqqe8avxtiumw...@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'. (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. (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. * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto thierry.volpiatto-re5jqeeqqe8avxtiumw...@public.gmane.org :GMANE_URL: http://mid.gmane.org/877gfqkm9t.fsf-re5jqeeqqe8avxtiumw...@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. Best regards, Seb Best regards, Michael.
Re: [O] Org mode issue tracker
Hi Suvayu, Suvayu Ali wrote: On Thu, Sep 26, 2013 at 09:29:10AM +0200, Sebastien Vauban wrote: (date . 1376383861) * TODO . :24.3: 2013-08-13 Tue I'd use the inactive version of the timestamp, that is (for Michael) [2013-08-13 Tue]. Doesn't the agenda show active timestamps only? Yes, but then I don't expect an event timestamp. Developers working on bugs might want to add the file as their agenda file. Absolutely, but the question comes down to: do they want to have their today's agenda filled with Org bugs? If they add `org-issues.org' to their `org-agenda-files', that's clear they wanna have the pendings bugs, etc. in *some* custom agenda views, but do they want that always in the default agenda? Adding the bug as an event timestamp will show it only on that day. Then, you don't see it anymore... If you want to see them, I'd propose to put a SCHEDULED type of timestamp, or a DEADLINE one, no? If you don't need the bugs in your default agenda view, then you can still put the date as an inactive timestamp to keep track of when the bug was submitted. Another way (to what you show) would be to add it under a property `Created' or `CreatedOn'... Best regards, Seb -- Sebastien Vauban
Re: [O] Org mode issue tracker
Hello Michael, On Thu, Sep 26, 2013 at 11:34:31AM +0200, Michael Albinus wrote: Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org 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-re5jqeeqqe8avxtiumw...@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 thierry.volpiatto-re5jqeeqqe8avxtiumw...@public.gmane.org :GMANE_URL: http://mid.gmane.org/877gfqkm9t.fsf-re5jqeeqqe8avxtiumw...@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
Re: [O] Org mode issue tracker
On Thu, Sep 26, 2013 at 02:13:19PM +0200, Suvayu Ali wrote: 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. I forgot to add; regarding your comment about retrieving several messages might be expensive, there could be an elisp link or a babel source block that does this on demand. -- Suvayu Open source is the future. It sets us free.
Re: [O] Org mode issue tracker
Suvayu Ali fatkasuvayu+li...@gmail.com writes: I forgot to add; regarding your comment about retrieving several messages might be expensive, there could be an elisp link or a babel source block that does this on demand. Elisp link is the beast I was looking for, thanks. Likely, there is no need for a babel source block. Best regards, Michael.
Re: [O] Org mode issue tracker
Hi, Suvayu Ali fatkasuvayu+li...@gmail.com writes: * TODO Subject timestamp :emacs_ver:org_ver:org_module: ... Emacs version ends up as a tag: * TODO . :24.3: Or, if I add an Org version: * TODO . :24.3:8.0.3: These bare numbers seem a bit too anonymous to me. I think it's unlikely that Org will reach versions in the 20's anytime soon so collision won't happen for a while but eventually (hackers willing!) it will. So, I suggest simply qualifying the versions like: * TODO . :emacs_24.3:org_8.0.3: I can also see a desire to list other software and their versions that might be implicated in the bug being reported. Listing their bare versions as tags is, I think, obviously no good. They could just include this info in an ad-hoc manner in the body of their report, but maybe it would be good to define a property to explicitly list them following the same package_version pattern of the tags. * TODO . :emacs_24.3:org_8.0.3: :PROPERTIES: :IMPLICATED_SOFTWARE: texlive_2012.20120611-5 beamer_3.10-2 BTW, I think an issue tracker in Org is very interesting. I look forward to seeing how it evolves. -Brett. pgp6kwuMSCpiV.pgp Description: PGP signature
[O] Org mode issue tracker
Hi everyone, we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html Note that I do not enter every issue into this file. Normally I wait and see if a report gets addressed on the mailing list, and only if that does not happen, than I make a note in this file. I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. If you feel that this is not going well enough and if I am missing important reports in this way, let me know and we will find a better solution. Some of these bugs still need confirmation by a second party, and patches are always welcome. If possible, reply in the original thread, while still mentioning the bug number in the above link. Regards - Carsten signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Org mode issue tracker
Hi, I was going to ask about this. The website actually does direct people to a collaborative issue tracker on Worg: http://orgmode.org/worg/org-issues.html As outlined there, the idea was that the maintainer would add issues from the mailing list, but others were welcome to modify the entries, e.g. to assign an issue to themselves. It's a nice idea, but it doesn't seem to have been regularly used since 2011 or so (?). Yours, Christian Carsten Dominik writes: Hi everyone, we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html (...) I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list.
Re: [O] Org mode issue tracker
On 25.9.2013, at 09:28, Christian Moe m...@christianmoe.com wrote: Hi, I was going to ask about this. The website actually does direct people to a collaborative issue tracker on Worg: http://orgmode.org/worg/org-issues.html Ha, I completely forgot about this one, and it seems to be entirely out of date. And I don't think it ever *really* worked. For now I am comfortable to do most of the tracking in the mailing list. Lets trash this old list and use the new one for now, while we think about a realistic system. - Carsten replace it with my new list. As outlined there, the idea was that the maintainer would add issues from the mailing list, but others were welcome to modify the entries, e.g. to assign an issue to themselves. It's a nice idea, but it doesn't seem to have been regularly used since 2011 or so (?). Yours, Christian Carsten Dominik writes: Hi everyone, we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html (...) I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Org mode issue tracker
Hi Carsten, Carsten Dominik wrote: we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html Note that I do not enter every issue into this file. Normally I wait and see if a report gets addressed on the mailing list, and only if that does not happen, than I make a note in this file. I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. If you feel that this is not going well enough and if I am missing important reports in this way, let me know and we will find a better solution. Some of these bugs still need confirmation by a second party, and patches are always welcome. If possible, reply in the original thread, while still mentioning the bug number in the above link. The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! But shouldn't it, maybe, be in a Git project, so that other people can edit it? And choosing to have the `Assignee' (or `ASSIGNEE') property be the official Org way to delegate a task to someone would help? Regarding the list itself, if I may, I would add 3 problems (identified by the date and time it has been sent on the Org mailing list): 1. 20130315.1805: Background color reset for links and DONE headlines Allow to have more faces than just `org-headline-done' when `DONE' (`org-fontify-done-headline'). I looked at it, following Bastien's hints, but never could make it work. 2. 20130909.1657: Clocktable error with multiple source files from parent dir 3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo' The following agenda view is supposed to display the tasks by ascending DEADLINE timestamp. (add-to-list 'org-agenda-custom-commands '(B Today tags-todo DEADLINE=\today\ ((org-agenda-overriding-header Today) (org-agenda-sorting-strategy '(deadline-up t) it sorts the list by category, instead! OTOH, you can delegate the problem #24 to me. - 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda I'll try to debug and fix it myself. I'll come back if I don't succeed. Best regards, Seb -- Sebastien Vauban
Re: [O] Org mode issue tracker
On 25.9.2013, at 09:51, Sebastien Vauban sva-n...@mygooglest.com wrote: Hi Carsten, Carsten Dominik wrote: we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html Note that I do not enter every issue into this file. Normally I wait and see if a report gets addressed on the mailing list, and only if that does not happen, than I make a note in this file. I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. If you feel that this is not going well enough and if I am missing important reports in this way, let me know and we will find a better solution. Some of these bugs still need confirmation by a second party, and patches are always welcome. If possible, reply in the original thread, while still mentioning the bug number in the above link. The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! But shouldn't it, maybe, be in a Git project, so that other people can edit it? And choosing to have the `Assignee' (or `ASSIGNEE') property be the official Org way to delegate a task to someone would help? Regarding the list itself, if I may, I would add 3 problems (identified by the date and time it has been sent on the Org mailing list): To make my life easier, cold you please provide gmane links? 1. 20130315.1805: Background color reset for links and DONE headlines Allow to have more faces than just `org-headline-done' when `DONE' (`org-fontify-done-headline'). I looked at it, following Bastien's hints, but never could make it work. 2. 20130909.1657: Clocktable error with multiple source files from parent dir 3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo' The following agenda view is supposed to display the tasks by ascending DEADLINE timestamp. (add-to-list 'org-agenda-custom-commands '(B Today tags-todo DEADLINE=\today\ ((org-agenda-overriding-header Today) (org-agenda-sorting-strategy '(deadline-up t) it sorts the list by category, instead! OTOH, you can delegate the problem #24 to me. - 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda I'll try to debug and fix it myself. I'll come back if I don't succeed. OK, will do that, thank you. - Carsten Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Org mode issue tracker
On Wed, Sep 25, 2013 at 09:51:20AM +0200, Sebastien Vauban wrote: The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! I think this is a great idea. A combination of an Org file (either public or private) and the Emacs bug tracker with Org package tags should be able to handle our needs. I see only one potential problem, is there an easy way to subscribe to only a specific package tag on the Emacs bug tracker? I imagine most contributors following Org bugs will not be interested in other Emacs bugs. -- Suvayu Open source is the future. It sets us free.
Re: [O] Org mode issue tracker
On 25.9.2013, at 08:43, Carsten Dominik carsten.domi...@gmail.com wrote: Hi everyone, we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html I have moved the tracker to Worg, discarding the old tracker file that was at that location. http://orgmode.org/worg/org-issues.html - Carsten Note that I do not enter every issue into this file. Normally I wait and see if a report gets addressed on the mailing list, and only if that does not happen, than I make a note in this file. I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. If you feel that this is not going well enough and if I am missing important reports in this way, let me know and we will find a better solution. Some of these bugs still need confirmation by a second party, and patches are always welcome. If possible, reply in the original thread, while still mentioning the bug number in the above link. Regards - Carsten signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Org mode issue tracker
Carsten Dominik wrote: On 25.9.2013, at 09:51, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html Note that I do not enter every issue into this file. Normally I wait and see if a report gets addressed on the mailing list, and only if that does not happen, than I make a note in this file. I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. If you feel that this is not going well enough and if I am missing important reports in this way, let me know and we will find a better solution. Some of these bugs still need confirmation by a second party, and patches are always welcome. If possible, reply in the original thread, while still mentioning the bug number in the above link. The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! But shouldn't it, maybe, be in a Git project, so that other people can edit it? And choosing to have the `Assignee' (or `ASSIGNEE') property be the official Org way to delegate a task to someone would help? Regarding the list itself, if I may, I would add 3 problems (identified by the date and time it has been sent on the Org mailing list): To make my life easier, cold you please provide gmane links? DONE ;-) See below. 1. 20130315.1805: Background color reset for links and DONE headlines Allow to have more faces than just `org-headline-done' when `DONE' (`org-fontify-done-headline'). I looked at it, following Bastien's hints, but never could make it work. http://permalink.gmane.org/gmane.emacs.orgmode/68552 2. 20130909.1657: Clocktable error with multiple source files from parent dir http://comments.gmane.org/gmane.emacs.orgmode/76207 3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo' The following agenda view is supposed to display the tasks by ascending DEADLINE timestamp. (add-to-list 'org-agenda-custom-commands '(B Today tags-todo DEADLINE=\today\ ((org-agenda-overriding-header Today) (org-agenda-sorting-strategy '(deadline-up t) it sorts the list by category, instead! http://permalink.gmane.org/gmane.emacs.orgmode/76347 OTOH, you can delegate the problem #24 to me. - 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda I'll try to debug and fix it myself. I'll come back if I don't succeed. OK, will do that, thank you. Best regards, Seb -- Sebastien Vauban
Re: [O] Org mode issue tracker
Hi Suvayu, Suvayu Ali wrote: On Wed, Sep 25, 2013 at 09:51:20AM +0200, Sebastien Vauban wrote: The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! I think this is a great idea. A combination of an Org file (either public or private) and the Emacs bug tracker with Org package tags should be able to handle our needs. I see only one potential problem, is there an easy way to subscribe to only a specific package tag on the Emacs bug tracker? I imagine most contributors following Org bugs will not be interested in other Emacs bugs. I don't know. I guess this should be asked directly to them. Indeed, it'd be good to have a (virtual) newsgroup with only bugs related to `org', like what exists for Stack Overflow. Best regards, Seb -- Sebastien Vauban
Re: [O] Org mode issue tracker
Hi Sebastiaan, I have added your issues. (P.S. this sounds really funny and reminds me of Marvin from the Hitchhikers Guide to the Galaxy does solve all of the major mathematical, physical, chemical, biological, sociological, philosophical, etymological,meteorological and psychological problems of the Universe *except his own*, three times over,) - Carsten On 25.9.2013, at 11:04, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 25.9.2013, at 09:51, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html Note that I do not enter every issue into this file. Normally I wait and see if a report gets addressed on the mailing list, and only if that does not happen, than I make a note in this file. I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. If you feel that this is not going well enough and if I am missing important reports in this way, let me know and we will find a better solution. Some of these bugs still need confirmation by a second party, and patches are always welcome. If possible, reply in the original thread, while still mentioning the bug number in the above link. The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! But shouldn't it, maybe, be in a Git project, so that other people can edit it? And choosing to have the `Assignee' (or `ASSIGNEE') property be the official Org way to delegate a task to someone would help? Regarding the list itself, if I may, I would add 3 problems (identified by the date and time it has been sent on the Org mailing list): To make my life easier, cold you please provide gmane links? DONE ;-) See below. 1. 20130315.1805: Background color reset for links and DONE headlines Allow to have more faces than just `org-headline-done' when `DONE' (`org-fontify-done-headline'). I looked at it, following Bastien's hints, but never could make it work. http://permalink.gmane.org/gmane.emacs.orgmode/68552 2. 20130909.1657: Clocktable error with multiple source files from parent dir http://comments.gmane.org/gmane.emacs.orgmode/76207 3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo' The following agenda view is supposed to display the tasks by ascending DEADLINE timestamp. (add-to-list 'org-agenda-custom-commands '(B Today tags-todo DEADLINE=\today\ ((org-agenda-overriding-header Today) (org-agenda-sorting-strategy '(deadline-up t) it sorts the list by category, instead! http://permalink.gmane.org/gmane.emacs.orgmode/76347 OTOH, you can delegate the problem #24 to me. - 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda I'll try to debug and fix it myself. I'll come back if I don't succeed. OK, will do that, thank you. Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Org mode issue tracker
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Hi Suvayu, Hi, The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! I think this is a great idea. A combination of an Org file (either public or private) and the Emacs bug tracker with Org package tags should be able to handle our needs. I see only one potential problem, is there an easy way to subscribe to only a specific package tag on the Emacs bug tracker? I imagine most contributors following Org bugs will not be interested in other Emacs bugs. I don't know. I guess this should be asked directly to them. Indeed, it'd be good to have a (virtual) newsgroup with only bugs related to `org', like what exists for Stack Overflow. There is the debbugs package on ELPA. The frontend, debbugs-gnu, allows to filter for packages and tags. Try (debbugs-gnu '(serious important normal) '(org-mode)) On my wannabe todo list is a package debbugs-org.el, which shows the entries as TODO items. If the org community decides to use debbugs as issue tracker, it would give me a push. (I'm not so experienced with org-mode, so I would need at least some assistance how such a TODO item should look like) Best regards, Seb Best regards, Michael.
Re: [O] Org mode issue tracker
Hi Michael, Michael Albinus wrote: Sebastien Vauban sva-n...@mygooglest.com The other solution that I'd see would be using Emacs' own bug tracker (the `org' package is already known to them), if that's possible. Anyway, having the bugs in an Org file seems natural too! I think this is a great idea. A combination of an Org file (either public or private) and the Emacs bug tracker with Org package tags should be able to handle our needs. I see only one potential problem, is there an easy way to subscribe to only a specific package tag on the Emacs bug tracker? I imagine most contributors following Org bugs will not be interested in other Emacs bugs. I don't know. I guess this should be asked directly to them. Indeed, it'd be good to have a (virtual) newsgroup with only bugs related to `org', like what exists for Stack Overflow. There is the debbugs package on ELPA. The frontend, debbugs-gnu, allows to filter for packages and tags. Try (debbugs-gnu '(serious important normal) '(org-mode)) I did not know. I must try it, for sure! It may be easier than the Web interface, which I find sometimes difficult to use (to find one's bug without remembering its ID). On my wannabe todo list is a package debbugs-org.el, which shows the entries as TODO items. If the org community decides to use debbugs as issue tracker, it would give me a push. I'd find that a promising feature... (I'm not so experienced with org-mode, so I would need at least some assistance how such a TODO item should look like) I don't think that's the problem ;-) Best regards, Seb -- Sebastien Vauban
Re: [O] Org mode issue tracker
(I'm not so experienced with org-mode, so I would need at least some assistance how such a TODO item should look like) A 'headline' is a 'TODO item' if-and-only-if it contains one of the TODO Keywords in the appropriate position. See: http://orgmode.org/worg/dev/org-syntax.html While you're in that document, have a look at the various structures that can live inside a headline (for example, timestamps). Everyone: Is that a proper answer to the question? :) Thank you, --Dave
Re: [O] Org mode issue tracker
Hi Carsten, Carsten Dominik wrote: I have moved the tracker to Worg, discarding the old tracker file that was at that location. http://orgmode.org/worg/org-issues.html Please note that the Show Org source button still shows the old Org file. Best regards, Seb -- Sebastien Vauban
Re: [O] Org mode issue tracker
On Wed, Sep 25, 2013 at 06:29:26PM +, Loyall, David wrote: (I'm not so experienced with org-mode, so I would need at least some assistance how such a TODO item should look like) A 'headline' is a 'TODO item' if-and-only-if it contains one of the TODO Keywords in the appropriate position. See: http://orgmode.org/worg/dev/org-syntax.html While you're in that document, have a look at the various structures that can live inside a headline (for example, timestamps). Everyone: Is that a proper answer to the question? :) Yes and no. The pointer to the syntax is spot on. But what would have made it complete was a pointer to the API docs. After all no need for David to reimplement things. Since he needs to work with TODOs, the following section in the manual should help. http://orgmode.org/manual/Using-the-mapping-API.html#Using-the-mapping-API -- Suvayu Open source is the future. It sets us free.
Re: [O] Org mode issue tracker
Loyall, David david.loy...@nebraska.gov writes: (I'm not so experienced with org-mode, so I would need at least some assistance how such a TODO item should look like) A 'headline' is a 'TODO item' if-and-only-if it contains one of the TODO Keywords in the appropriate position. See: http://orgmode.org/worg/dev/org-syntax.html While you're in that document, have a look at the various structures that can live inside a headline (for example, timestamps). Thanks. I've contacted already the org info pages, in order to get an idea what's possible. But a general doc is one thing, a mapping of a debbugs record onto a TODO entry is another one. Let's check it with an example. For bug 15081, debbugs-gnu returns the following list: ((source . unknown) (found_versions 24.3) (done) (blocks) (date . 1376383861) (fixed) (fixed_versions) (mergedwith) (found (item (key . 24.3) (value))) (unarchived) (blockedby) (keywords) (summary) (msgid . 877gfqkm9t@gmail.com) (id . 15081) (forwarded) (severity . normal) (owner) (log_modified . 1376383862) (location . db-h) (subject . 24.3; org-crypt: Making epg-context local to *epg* while let-bound!) (originator . Thierry Volpiatto thierry.volpia...@gmail.com) (last_modified . 1376408720) (pending . pending) (affects) (archived) (tags) (package emacs org-mode) (fixed_date) (found_date) (bug_num . 15081)) The keys shall be self-explaining. How would a TODO item look like? Note, that these metadata do not contain the corresponding messages yet. debbugs-gnu could retrieve them in a second run; the TODO item shall offer a link to them, inline. Thank you, --Dave Best regards, Michael.
Re: [O] Org mode issue tracker
Hi Sébastien, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Please note that the Show Org source button still shows the old Org file. Indeed -- the sources for all Worg files were not properly updated, I just fixed this. Thanks! -- Bastien
Re: [O] Org mode issue tracker
Hello Michael, This is the general structure I'm proposing: * TODO Subject timestamp :emacs_ver:org_ver:org_module: :PROPERTIES: :DEBGUGS_ID: bug number :REPORTER:Reporter Name :CC_EMAIL:list of emails of interested parties :END: I elaborate the ideas below. On Wed, Sep 25, 2013 at 08:56:50PM +0200, Michael Albinus wrote: Let's check it with an example. For bug 15081, debbugs-gnu returns the following list: ((source . unknown) (found_versions 24.3) Emacs version ends up as a tag: * TODO . :24.3: (done) (blocks) (date . 1376383861) * TODO . :24.3: 2013-08-13 Tue (fixed) (fixed_versions) (mergedwith) (found (item (key . 24.3) (value))) (unarchived) (blockedby) (keywords) (summary) (msgid . 877gfqkm9t@gmail.com) An added bonus idea: Gmane has this amazing feature where you can link to a message using it's message id. So a property like: GMANE_URL would be awesome. * TODO . :24.3: :PROPERTIES: :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 2013-08-13 Tue (id . 15081) * TODO . :24.3: :PROPERTIES: :DEBGUGS_ID: 15081 :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 2013-08-13 Tue It would be cool if you could provide a function that uses browse-url to direct you to the webpage using DEBGUGS_ID: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15081 (forwarded) (severity . normal) (owner) (log_modified . 1376383862) (location . db-h) (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@gmail.com :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). (originator . Thierry Volpiatto thierry.volpia...@gmail.com) * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto thierry.volpia...@gmail.com :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 2013-08-13 Tue (last_modified . 1376408720) Maybe this should go into a property called: LAST_MODIFIED. (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) (affects) (archived) (tags) (package emacs org-mode) I guess this is how you filter out org-mode bugs from the rest. (fixed_date) (found_date) (bug_num . 15081)) The keys shall be self-explaining. How would a TODO item look like? Note, that these metadata do not contain the corresponding messages yet. debbugs-gnu could retrieve them in a second run; the TODO item shall offer a link to them, inline. So finally I propose the following for this particular bug. * TODO Making epg-context local to *epg* while let-bound! :24.3:org_crypt: :PROPERTIES: :DEBGUGS_ID: 15081 :REPORTER: Thierry Volpiatto thierry.volpia...@gmail.com :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com :END: 152 2013-08-13 Tue However in this example there were no interested parties. If you take this (non org-mode) bug as an example: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15282, the CC_EMAIL property would be: Eli Zaretskii e...@gnu.org, Gregor Zattler telegr...@gmx.net, hyper...@debian.org, Paul Eggert egg...@cs.ucla.edu, and all the contributors to bug 15222 (that would be me :-p, Suvayu Ali fatkasuvayu+li...@gmail.com). What do others think? Is it a good start? Overall this looks very promising, I am excited :). Cheers, -- Suvayu Open source is the future. It sets us free.
