--- /dev/null
+On Mon, Jul 20, 2009 at 05:03:18PM -0400, Chris Ball wrote:
+> Hi Gianluca,
+>
+> > In any case, having the possibility to set a due date does not
+> > means that it is obligatory to do it and should be a good idea to
+> > offer as many possibilities as we can to the users of BE
+>
+> Okay, sounds reasonable. Would you like to write a patch for
+> associating due dates and open/closed with a target?
+
+I've been mulling this over, and I think that targets are a lot like
+bugs. Here's a list of issue/implementation pairs:
+
+ * Targeting normal bugs
+
+ With "be depend". I think we should remove the "target" field from
+ bugs, and move target dependencies over into the "be depend"
+ framework. Of course, we could add "blocks" (in addition to the
+ current "blocked-by") tags to make target lookup more efficient.
+
+ * "due_by"
+
+ We could add "due-by" to Bug.extra_strings as well, so that anyone
+ could set due dates for any issue they wanted.
+
+ * Bugdir-wide target
+
+ Just a pointer to the current target bug.
+
+ * Target dependency tree / time-series.
+
+ Use BLOCKS/BLOCKED-BY tags between targets, so you'd know which ones
+ came first.
+
+ * be target list
+
+ Would become "be list --severity target". A target "severity" would
+ keep target bugs distinct from other bug/issue types.
+
+ * Commenting on targets
+
+ They'd be Bug()s, so commenting already build in, e.g. to add
+ release notes, layout roadmaps, etc.
+
+If you want, we could maintain the current "be target" interface,
+and just use all this stuff behind the scenes.
+
+Thoughts?
+Trevor
+
+--
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
projects / be.git / commitdiff