* [PATCH] Smart inference of task progress when exporting to TJ3 @ 2013-05-02 21:24 Martin 2013-05-03 8:40 ` Daimrod 0 siblings, 1 reply; 9+ messages in thread From: Martin @ 2013-05-02 21:24 UTC (permalink / raw) To: emacs-orgmode * contrib/lisp/ox-taskjuggler.el: Extend variable `complete' to respect clock times if no other information is given. There are three possibilities for setting a task's progress when exporting to TJ3: 1) If TODO state equals "done" => 100% 2) If property "complete" is explicitly given => use that. 3) Otherwise get the clocksum of the task and set the progress by comparing to `effort'. TINYCHANGE --- contrib/lisp/ox-taskjuggler.el | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el index 3458e06..a97c075 100644 --- a/contrib/lisp/ox-taskjuggler.el +++ b/contrib/lisp/ox-taskjuggler.el @@ -780,6 +780,16 @@ channel." ;; Closing report. "}\n")) + +(defun org-taskjuggler--clocksum-task (task) +"Return the clocksum of a parsed subtree => does not verify whether the parsed duration matches the start and end times" +(let* ((tsum 0)) + (org-element-map (org-element-contents task) 'clock + (lambda (hl) (setq tsum (+ tsum (org-duration-string-to-minutes (org-element-property :duration hl))))) + ) + tsum +)) + (defun org-taskjuggler--build-task (task info) "Return a task declaration. @@ -791,11 +801,24 @@ a property \"task_id\" it will be used as the id for this task. Otherwise it will use the ID property. If neither is defined a unique id will be associated to it." (let* ((allocate (org-element-property :ALLOCATE task)) + (effort (org-element-property :EFFORT task)) + ;; smart completeness inference: + ;; - if state=done => 100% + ;; - if explicit property for "complete" => take that value + ;; - otherwise get clocksum of this task and relate to the effort, whilst limiting values to [0,99] + ;; => 100% possible if and only if state=DONE. Overbooking does stop at 99%. + (complete-explicit (org-element-property :COMPLETE task)) (complete - (if (eq (org-element-property :todo-type task) 'done) "100" - (org-element-property :COMPLETE task))) + ;; state=done => complete=100 + (if (eq (org-element-property :todo-type task) 'done) 100.0 + ;; else if explicit property => use that + (if complete-explicit (string-to-number complete-explicit) + ;; else guess the completeness from clocksum + (let* ((clocked (org-taskjuggler--clocksum-task task)) + (complete-guess (and effort (/ (* 100 clocked) (org-duration-string-to-minutes effort))))) + (and complete-guess (max (min 99 complete-guess) 0))) ;; check ranges and don't set complete=100 until state=DONE + ))) (depends (org-taskjuggler-resolve-dependencies task info)) - (effort (org-element-property :EFFORT task)) (milestone (or (org-element-property :MILESTONE task) (not (or (org-element-map (org-element-contents task) 'headline @@ -826,7 +849,7 @@ a unique id will be associated to it." (if (>= org-taskjuggler-target-version 3.0) "allocate" "allocations") allocate)) - (and complete (format " complete %s\n" complete)) + (and complete (format " complete %.1f\n" complete)) (and effort (format " effort %s\n" (let* ((minutes (org-duration-string-to-minutes effort)) -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-02 21:24 [PATCH] Smart inference of task progress when exporting to TJ3 Martin @ 2013-05-03 8:40 ` Daimrod 2013-05-03 11:26 ` Martin Becker 0 siblings, 1 reply; 9+ messages in thread From: Daimrod @ 2013-05-03 8:40 UTC (permalink / raw) To: Martin; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 643 bytes --] Martin <vbmazter@web.de> writes: Hello Martin, Thanks for your patch. I will only make a few stylistic remarks. 1. Could you add `contrib/lisp/ox-taskjuggler.el:' to the subject? (The first line of the commit message) 2. IIUC you don't need the TINYCHANGE cookie because the changes are made in contrib/ which doesn't require copyright assignment. Furthermore, I don't think your changes could be considered `tiny' (it changes more than 20 lines and doesn't look like a rewrite). 3. Could you reformat a bit your code so it fit in 80 column? (You can often use M-q for the comments) -- Daimrod/Greg [-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-03 8:40 ` Daimrod @ 2013-05-03 11:26 ` Martin Becker 2013-05-03 15:08 ` Christian Egli 0 siblings, 1 reply; 9+ messages in thread From: Martin Becker @ 2013-05-03 11:26 UTC (permalink / raw) To: Daimrod; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 771 bytes --] Dear Daimrod, Thank you for these remarks, next time I know. I attached a "clean" patch. On 03.05.2013 10:40, Daimrod wrote: > Martin <vbmazter@web.de> writes: > > Hello Martin, > > Thanks for your patch. I will only make a few stylistic remarks. > > 1. Could you add `contrib/lisp/ox-taskjuggler.el:' to the subject? (The > first line of the commit message) > > 2. IIUC you don't need the TINYCHANGE cookie because the changes are > made in contrib/ which doesn't require copyright assignment. > Furthermore, I don't think your changes could be considered `tiny' > (it changes more than 20 lines and doesn't look like a rewrite). > > 3. Could you reformat a bit your code so it fit in 80 column? (You can > often use M-q for the comments) > [-- Attachment #2: 0001-contrib-lisp-ox-taskjuggler.el-Smart-inference-of-ta.patch --] [-- Type: text/x-patch, Size: 3700 bytes --] From ec5076f93678a3ca5d0944cd777a0d87c74dfeee Mon Sep 17 00:00:00 2001 From: Martin Becker <vbmazter@web.de> Date: Thu, 2 May 2013 23:08:40 +0200 Subject: [PATCH] contrib/lisp/ox-taskjuggler.el: Smart inference of task progress when exporting to TJ3 * contrib/lisp/ox-taskjuggler.el: Extend variable `complete' to respect clock times if no other information is given. There are three possibilities for setting a task's progress when exporting to TJ3: 1) If TODO state equals "done" => 100% 2) If property "complete" is explicitly given => use that. 3) Otherwise get the clocksum of the task and set the progress by comparing to `effort'. --- contrib/lisp/ox-taskjuggler.el | 36 ++++++++++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el index 3458e06..97c4aae 100644 --- a/contrib/lisp/ox-taskjuggler.el +++ b/contrib/lisp/ox-taskjuggler.el @@ -780,6 +780,17 @@ channel." ;; Closing report. "}\n")) + +(defun org-taskjuggler--clocksum-task (task) + "Return the clocksum of a parsed subtree => does not verify +whether the parsed duration matches the start and end times" + (let* ((tsum 0)) + (org-element-map (org-element-contents task) 'clock + (lambda (hl) (setq tsum (+ tsum (org-duration-string-to-minutes + (org-element-property :duration hl)))))) + tsum + )) + (defun org-taskjuggler--build-task (task info) "Return a task declaration. @@ -791,11 +802,28 @@ a property \"task_id\" it will be used as the id for this task. Otherwise it will use the ID property. If neither is defined a unique id will be associated to it." (let* ((allocate (org-element-property :ALLOCATE task)) + (effort (org-element-property :EFFORT task)) + ;; smart completeness inference: + ;; - if state=done => 100% + ;; - if explicit property for "complete" => take that value + ;; - otherwise get clocksum of this task and relate to the + ;; effort, whilst limiting values to [0,99] + ;; => 100% possible if and only if state=DONE. + ;; Overbooking does stop at 99%. + (complete-explicit (org-element-property :COMPLETE task)) (complete - (if (eq (org-element-property :todo-type task) 'done) "100" - (org-element-property :COMPLETE task))) + ;; state=done => complete=100 + (if (eq (org-element-property :todo-type task) 'done) 100.0 + ;; else if explicit property => use that + (if complete-explicit (string-to-number complete-explicit) + ;; else guess the completeness from clocksum + (let* ((clocked (org-taskjuggler--clocksum-task task)) + (complete-guess + (and effort (/ (* 100 clocked) + (org-duration-string-to-minutes effort))))) + (and complete-guess (max (min 99 complete-guess) 0))) + ))) (depends (org-taskjuggler-resolve-dependencies task info)) - (effort (org-element-property :EFFORT task)) (milestone (or (org-element-property :MILESTONE task) (not (or (org-element-map (org-element-contents task) 'headline @@ -826,7 +854,7 @@ a unique id will be associated to it." (if (>= org-taskjuggler-target-version 3.0) "allocate" "allocations") allocate)) - (and complete (format " complete %s\n" complete)) + (and complete (format " complete %.1f\n" complete)) (and effort (format " effort %s\n" (let* ((minutes (org-duration-string-to-minutes effort)) -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-03 11:26 ` Martin Becker @ 2013-05-03 15:08 ` Christian Egli 2013-05-03 17:05 ` Martin Becker 2013-05-07 10:08 ` Bastien 0 siblings, 2 replies; 9+ messages in thread From: Christian Egli @ 2013-05-03 15:08 UTC (permalink / raw) To: emacs-orgmode Hi Martin Martin Becker <vbmazter@web.de> writes: > Thank you for these remarks, next time I know. > I attached a "clean" patch. I like this patch, this is good stuff. Can you tell me how you use this? I.e. does tj3 adapt the length fo a task based on your clock table? A few remarks on the patch from my side: + ;; state=done => complete=100 + (if (eq (org-element-property :todo-type task) 'done) 100.0 + ;; else if explicit property => use that + (if complete-explicit (string-to-number complete-explicit) + ;; else guess the completeness from clocksum + (let* ((clocked (org-taskjuggler--clocksum-task task)) + (complete-guess + (and effort (/ (* 100 clocked) + (org-duration-string-to-minutes effort))))) + (and complete-guess (max (min 99 complete-guess) 0))) + ))) I would write this using cond instead of nested if. Makes it more clear. >> 2. IIUC you don't need the TINYCHANGE cookie because the changes >> are made in contrib/ which doesn't require copyright assignment. The taskjuggler exporter used to be in core before it was moved to contrib by Bastien or Nicolas on the bases that there aren't many users (and probably because it wasn't maintained very well). This is OK for now, but eventually I'd like to move it back to core. So we need assignment for this patch. Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-03 15:08 ` Christian Egli @ 2013-05-03 17:05 ` Martin Becker 2013-05-03 20:25 ` Christian Egli 2013-05-07 10:08 ` Bastien 1 sibling, 1 reply; 9+ messages in thread From: Martin Becker @ 2013-05-03 17:05 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1.1: Type: text/plain, Size: 2527 bytes --] Hi Christian, > I like this patch, this is good stuff. Can you tell me how you use > this? Thanks, I attached a file where I made some tests. My idea was, that clock times are only used when there is no explicit information given, viz., when there is neither a property `complete' nor the task state equals "done". Since I am clocking most of my activities, it would be convenient for me to let the exporter/TJ3 infer the task progress instead of explicitly giving the `complete' property. So far for the story. > I.e. does tj3 adapt the length fo a task based on your clock > table? No, TJ3 is not adapting anything here, neither am I. Since you cannot give values > 100 (%), my patch limits the maximum inferred progress to 99. We could let the exporter overwrite the effort with the clocksum in those cases, but it doesn't seem right. I found out some more details after reading the documentation of TJ3: - The `complete' property is merely for documentation purposes, it's totally ignored by TJ3 when it comes to scheduling. It just "looks nice". Being only "cosmetic", tracking can be done via clock times as proposed. - But there is another thing we could do: One can add "bookings" to the tasks, which could be exactly the clock times from org-mode. I tried this manually and it seems to be a mixed blessing: If doing so, TJ3 internally grows the effort when the bookings exceed them and reschedules accordingly (which is nice). On the other hand sensible clock times are vital then. What I mean is, when there are bookings that are too early w.r.t. a task's earliest possible start (due to dependencies etc.), then TJ3 exits with an error. I am not sure this is wanted behavior. What do you think? Additionally, the visually attractive completeness is not derived from the bookings or anything. > I would write this using cond instead of nested if. Makes it more > clear. Oh yes, I will do that. I am fairly new to Lisp, it is a nice exercise. >>> 2. IIUC you don't need the TINYCHANGE cookie because the changes >>> are made in contrib/ which doesn't require copyright assignment. > The taskjuggler exporter used to be in core before it was moved to > contrib by Bastien or Nicolas on the bases that there aren't many > users (and probably because it wasn't maintained very well). This is > OK for now, but eventually I'd like to move it back to core. So we > need assignment for this patch. Is it that I need to sign something? That is not a problem, I happily contribute here. [-- Attachment #1.2: Type: text/html, Size: 3296 bytes --] [-- Attachment #2: tj3test.org --] [-- Type: text/plain, Size: 4070 bytes --] #+PROPERTY: Effort_ALL 2d 5d 10d 20d 30d 35d 50d #+PROPERTY: allocate_ALL dev doc test #+PROPERTY: ORDERED_ALL true false #+COLUMNS: %70ITEM(Task) %3Effort %8allocate %BLOCKER %ORDERED * Resources :taskjuggler_resource: ** Developers :PROPERTIES: :resource_id: dev :END: *** Paul Smith :PROPERTIES: :resource_id: paul :END: *** Sébastien Bono :PROPERTIES: :resource_id: seb :END: *** Klaus Müller ** Others *** Peter Murphy :PROPERTIES: :resource_id: doc :limits: { dailymax 7h } :END: *** Dim Sung :PROPERTIES: :resource_id: test :END: * Accounting Software :taskjuggler_project: SCHEDULED: <2013-04-15 Mo> ** STARTED Specification - State "STARTED" from "TODO" [2013-05-02 Do 16:50] CLOCK: [2013-04-30 Do 16:50]--[2013-05-03 Do 16:50] => 72:00 :PROPERTIES: :Effort: 20d :allocate: dev :task_id: task_spec :END: ** Software Development :PROPERTIES: :allocate: dev :ORDERED: true :BLOCKER: previous-sibling :task_id: task_dev :END: *** TODO Database coupling CLOCK: [2013-05-03 Do 15:21]--[2013-05-11 Do 22:21] => 199:00 :PROPERTIES: :Effort: 20d :END: *This task uses the smart progress inference*: This task's completeness is guessed using the clocked times, since it has no explicit `complete' property. However the clock durations add up to more than the effort and TJ3 does only allow values [0,100]. Therefore semantically the task is not regarded as complete until the TODO state equals "done", no matter how much we clock on it. According to TJ3 doc, the complete information has no impact on the TJ3 scheduler, it's pure documentation. *Alternatives*: 1) Instead of setting `complete', we could set the property `booking' for a resource or task, when we export to TJ3. Then TJ3 would have additional information, since the bookings reflect how much work was actually put into a task vs. how much we originally planned. Note that unlike `complete' this has an impact on the scheduling. TJ3 then can schedule a new plan based on the amount of work that actually happened. Downside is, that the org-syntax does not capture who/which resource clocks on a task. And that the clock times will cause scheduling errors when they do not comply with the scheduled time windows for the tasks (e.g., when the bookings are earlier than the task could have started, which can be constrained by dependencies). When the bookings exceed the effort, TJ3 overwrites the effort with the booking value. No completeness is calculated automatically though. 2) We continue to set `complete', but when the progress rendered by the clocksum exceeds 100%, we adjust the effort s.t. it yields 99% again. However, this might be surprising since the export shows different efforts than the org-file. *** Back-End Functions :PROPERTIES: :Effort: 5d :task_id: task_backend :END: *** Graphical User Interface :PROPERTIES: :Effort: 35d :END: ** Software testing :PROPERTIES: :allocate: test, paul :ORDERED: true :BLOCKER: task_dev :END: *** Alpha Test :PROPERTIES: :Effort: 5d :task_id: task_alpha :END: *** Beta Test :PROPERTIES: :Effort: 20d :allocate: test :task_id: task_beta :END: ** Manual CLOCK: [2013-05-03 Fr 12:48]--[2013-05-08 Fr 17:48] => 125:00 :PROPERTIES: :Effort: 50d :allocate: doc :BLOCKER: task_spec :complete: 75 :task_id: task_manual :END: This task's completeness is explicitly set. Even if there are clock in this task, it is being ignored. ** Milestones *** Project start *** Technology Preview :PROPERTIES: :BLOCKER: task_backend :END: *** Beta version :PROPERTIES: :BLOCKER: task_alpha :END: *** Ship Product to Customer :PROPERTIES: :BLOCKER: task_beta task_manual :END: ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-03 17:05 ` Martin Becker @ 2013-05-03 20:25 ` Christian Egli 2013-05-03 23:06 ` Martin Becker 0 siblings, 1 reply; 9+ messages in thread From: Christian Egli @ 2013-05-03 20:25 UTC (permalink / raw) To: emacs-orgmode Hi Martin Martin Becker <vbmazter@web.de> writes: > My idea was, that clock times are only used when there is no explicit > information given, viz., when there is neither a property `complete' > nor the task state equals "done". Since I am clocking most of my > activities, it would be convenient for me to let the exporter/TJ3 > infer the task progress instead of explicitly giving the `complete' > property. So far for the story. Ah, I get it. You are infering the % complete based on how much effort you have already put into a task. The problem is that this doesn't always relate to each other: You might have put a lot of effort into a task and still be only at 10% complete. >> I.e. does tj3 adapt the length fo a task based on your clock >> table? > No, TJ3 is not adapting anything here, neither am I. Since you cannot > give values > 100 (%), my patch limits the maximum inferred progress > to 99. We could let the exporter overwrite the effort with the > clocksum in those cases, but it doesn't seem right. Yes, since this is another problem with infering the complete information from the planed effort and actual effort: You can end up with complete more than 100% :-), namely if the actual effort is bigger than the planed effort. > I found out some more details after reading the documentation of TJ3: > - The `complete' property is merely for documentation purposes, it's > totally ignored by TJ3 when it comes to scheduling. It just "looks > nice". Yes, I think there are some other draw backs with the complete information. Check the taskjuggler mailing list archives for a discussion on tracking the progress of a project (https://groups.google.com/d/topic/taskjuggler-users/ZCk_est4GKE/discussion). I for one would like it if were used for scheduling. > - But there is another thing we could do: One can add "bookings" to > the tasks, which could be exactly the clock times from org-mode. I > tried this manually and it seems to be a mixed blessing: If doing so, > TJ3 internally grows the effort when the bookings exceed them and > reschedules accordingly (which is nice). This is something that would make sense in the exporter. The clocking information that we have in the org file is really what tj3 wants as a booking. > On the other hand sensible clock times are vital then. What I mean is, > when there are bookings that are too early w.r.t. a task's earliest > possible start (due to dependencies etc.), then TJ3 exits with an > error. I am not sure this is wanted behavior. What do you think? Yes, it appears that you will have to have bookings for all the tasks to make this work properly. This is a lot of overhead. I'm also not sure this is wanted. But the benefit would be that you can use projection mode in which tj3 will afaik recalculate the duration of the project based an planed and actual effort. Might be worth exploring. > Additionally, the visually attractive completeness is not derived from > the bookings or anything. Yes. >> but eventually I'd like to move it back to core. So we need >> assignment for this patch. > Is it that I need to sign something? Have a look at request-assign-future.txt in the org-mode git repo. Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-03 20:25 ` Christian Egli @ 2013-05-03 23:06 ` Martin Becker 0 siblings, 0 replies; 9+ messages in thread From: Martin Becker @ 2013-05-03 23:06 UTC (permalink / raw) To: emacs-orgmode Hi again, On 03.05.2013 22:25, Christian Egli wrote: > Hi Martin > > Martin Becker <vbmazter@web.de> writes: > >> My idea was, that clock times are only used when there is no explicit >> information given, viz., when there is neither a property `complete' >> nor the task state equals "done". Since I am clocking most of my >> activities, it would be convenient for me to let the exporter/TJ3 >> infer the task progress instead of explicitly giving the `complete' >> property. So far for the story. > Ah, I get it. You are infering the % complete based on how much effort > you have already put into a task. The problem is that this doesn't > always relate to each other: You might have put a lot of effort into a > task and still be only at 10% complete. Of course this rarely works out like that. At least me, I am using such planning to see "how wrong" I was and what is the impact of that. Though, "booking" would be better for that as I learned meanwhile. >>> I.e. does tj3 adapt the length fo a task based on your clock >>> table? >> No, TJ3 is not adapting anything here, neither am I. Since you cannot >> give values > 100 (%), my patch limits the maximum inferred progress >> to 99. We could let the exporter overwrite the effort with the >> clocksum in those cases, but it doesn't seem right. > Yes, since this is another problem with infering the complete > information from the planed effort and actual effort: You can end up > with complete more than 100% :-), namely if the actual effort is bigger > than the planed effort. yes...see above. > >> I found out some more details after reading the documentation of TJ3: >> - The `complete' property is merely for documentation purposes, it's >> totally ignored by TJ3 when it comes to scheduling. It just "looks >> nice". > Yes, I think there are some other draw backs with the complete > information. Check the taskjuggler mailing list archives for a > discussion on tracking the progress of a project > (https://groups.google.com/d/topic/taskjuggler-users/ZCk_est4GKE/discussion). > I for one would like it if were used for scheduling. That's why I stopped the inferred progress at 99%...one never knows as the linked thread shows ;) Until there is a change in semantics for that property, it shouldn't hurt to guess it like that. >> - But there is another thing we could do: One can add "bookings" to >> the tasks, which could be exactly the clock times from org-mode. I >> tried this manually and it seems to be a mixed blessing: If doing so, >> TJ3 internally grows the effort when the bookings exceed them and >> reschedules accordingly (which is nice). > This is something that would make sense in the exporter. The clocking > information that we have in the org file is really what tj3 wants as a > booking. Agreed, I think that's much more interesting than `complete'. However is tricky to integrate that well without ending in bad (ox-taskjuggler) user experience caused by TJ3 refusing to schedule... >> On the other hand sensible clock times are vital then. What I mean is, >> when there are bookings that are too early w.r.t. a task's earliest >> possible start (due to dependencies etc.), then TJ3 exits with an >> error. I am not sure this is wanted behavior. What do you think? > Yes, it appears that you will have to have bookings for all the tasks to > make this work properly. This is a lot of overhead. I'm also not sure > this is wanted. But the benefit would be that you can use projection > mode in which tj3 will afaik recalculate the duration of the project > based an planed and actual effort. Might be worth exploring. I am not quiet through TJ3 doc to understand what projection really is, but it seems that booking only *some* tasks also makes a difference (as I said, it grows the effort if there was an underestimation and thereby affects the project timing). Eventually a user could clock and book just a subset of the tasks (e.g., his own) and skip others or whatever... > >> Additionally, the visually attractive completeness is not derived from >> the bookings or anything. > Yes. > >>> but eventually I'd like to move it back to core. So we need >>> assignment for this patch. >> Is it that I need to sign something? > Have a look at request-assign-future.txt in the org-mode git repo. Will do. > > Thanks > Christian > Thanks & have a nice weekend, Martin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-03 15:08 ` Christian Egli 2013-05-03 17:05 ` Martin Becker @ 2013-05-07 10:08 ` Bastien 2013-05-07 10:57 ` Bastien 1 sibling, 1 reply; 9+ messages in thread From: Bastien @ 2013-05-07 10:08 UTC (permalink / raw) To: Christian Egli; +Cc: emacs-orgmode Hi Christian, Christian Egli <christian.egli@sbs.ch> writes: > The taskjuggler exporter used to be in core before it was moved to > contrib by Bastien or Nicolas on the bases that there aren't many users > (and probably because it wasn't maintained very well). This is OK for > now, but eventually I'd like to move it back to core. So we need > assignment for this patch. The rationale for moving some files out of core is not only about the size of the user-base (which is very difficult to know), but mostly about whether those contributed packages depend on 3rd-part softwares. Here is how I stated this in the release notes: Since packages in Org's core are meant to be part of GNU Emacs, we try to be minimalist when it comes to adding files into core. For 8.0, we moved some contributions into the contrib/ directory. The rationale for deciding that these files should live in contrib/ is either because they rely on third-part softwares that are not included in Emacs, or because they are not targetting a significant user-base. For example, org-mew.el and org-wl.el were moved in contrib/ because Mew and Wanderlust are not part of Emacs. Same for org-mac-message.el. We made one exception for org-w3m.el because emacs-w3m is the most popular way of browsing the Web within Emacs *and* because there are ongoing discussions about integrating it in Emacs: http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00116.html I hope this clarifies why I made this choice. Let me know if you think it is too controversial! Best, -- Bastien ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Smart inference of task progress when exporting to TJ3 2013-05-07 10:08 ` Bastien @ 2013-05-07 10:57 ` Bastien 0 siblings, 0 replies; 9+ messages in thread From: Bastien @ 2013-05-07 10:57 UTC (permalink / raw) To: Christian Egli; +Cc: emacs-orgmode Bastien <bzg@gnu.org> writes: > The rationale for moving some files out of core is not only about the > size of the user-base (which is very difficult to know), but mostly > about whether those contributed packages depend on 3rd-part softwares. PS: Also see this recent message by Glenn: http://article.gmane.org/gmane.emacs.devel/159305 I think code for mailers that don't come with Emacs doesn't belong in Emacs. This is the reasoning I also tried to apply when deciding about whether a package should go into core or contrib. -- Bastien ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-05-07 10:57 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-02 21:24 [PATCH] Smart inference of task progress when exporting to TJ3 Martin 2013-05-03 8:40 ` Daimrod 2013-05-03 11:26 ` Martin Becker 2013-05-03 15:08 ` Christian Egli 2013-05-03 17:05 ` Martin Becker 2013-05-03 20:25 ` Christian Egli 2013-05-03 23:06 ` Martin Becker 2013-05-07 10:08 ` Bastien 2013-05-07 10:57 ` Bastien
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).