+Content-type: text/plain
-
-Content-type=text/plain
-
-
-
-
-
-
-Date=Mon, 17 Apr 2006 20:59:15 +0000
-
-
-
-
-
-
-From=abentley
+Date: Mon, 17 Apr 2006 20:59:15 +0000
+From: abentley
--- /dev/null
+This could be implemented with an external frontend storing the
+dependency data in arbitrary tags.
+
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 21:29:13 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
--- /dev/null
+Merged into bug 7ec2c071-9630-42b0-b08a-9854616f9144
\ No newline at end of file
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 21:29:33 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
+creator: abentley
+severity: minor
-creator=abentley
+status: closed
+summary: Indicate bug dependencies
-
-severity=minor
-
-
-
-
-
-
-status=open
-
-
-
-
-
-
-summary=Indicate bug dependencies
-
-
-
-
-
-
-time=Wed, 04 Jan 2006 21:05:37 +0000
-
-
+time: Wed, 04 Jan 2006 21:05:37 +0000
--- /dev/null
+In my Tue, 25 Nov 2008 08:30:19 -0500 email:
+
+Implemented as a free-form value field similar to target? A
+comma-seperated list of tags? Perhaps once we have per-bug/comment
+attribute searching it would be easier to have a 'create-attribute'
+becommand, e.g.
+ be create-attribute [-valid=X,Y,Z] [bugdir|bug|comment] [NAME] [DEFAULT]
+
+We could ship some suggested configuration scripts to set people up,
+and keep the core code more general/flexible.
+
+
+Plan:
+
+Extend and make more consitent the settings_property() attributes.
+Create becommand/(create/remove)-attribute for logic-less attributes.
+Create a few mix-ins for logic-ed attributes
+
+Usage example:
+ Goal:
+ set up for `be depends BUGA BUGB`, `be depends --tree BUGA`, etc
+ Procedure:
+ be set --apend mixins bug:dependency
+ Where we've defined
+ becommands/depends.py, but it is hidden until the mixin is activated
+ libbe/mixins/bug/dependency.Mixin (inheriting from BugMixin)
+ to
+ parse/generate comma seperated dependency uuids for saving/loading
+ pretty-print the dependency list (e.g. uuid->shortname)
+ walk the dependency tree and check target bug status.
+
+With more complicated mixins, there could be inter-mixin dependencies,
+e.g. a dependency tracker that searches depends based on bug.status
+might depend on the base dependency mixin. This way people who need
+it could make rich interfaces without confusing the people who don't.
+
+How does that sound?
+
+
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 20:39:39 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
--- /dev/null
+It's tricky to say whether we should have dependencies or reverse dependencies
+or both.
+
+In the case where a bug is removed, normal dependencies mean that its
+dependencies are erased from this system.
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 17 Apr 2006 20:59:15 +0000
+
+
+From: abentley
+
+
+In-reply-to: f87fd684-6af1-498d-98d5-f915bcee76a9
+
--- /dev/null
+From my Tue, 25 Nov 2008 13:27:12 -0500 email:
+
+> >> 7ec:om: Arbitrary tags
+> >> Sensible
+> >
+> > Implemented as a free-form value field similar to target? A
+> > comma-seperated list of tags?
+>
+
+That is a much better format than my unmergable one ;).
+
+> "append" usually has two "p"s. Is the omission deliberate?
+
+Nope, sorry :p
+
+> It sounds pretty complicated. I would probably use a type system rather
+> than "mixins", and define types as "scalar", "set" and maybe "list" and
+> "map". Dependencies would be a set, and their special behaviour would
+> be hardcoded according to their name, not a property of their type.
+
+Ok. I'm just worried about bloat. It's pretty easy to move things
+around at the moment, but I'm worried that adding lots of attributes
+with special code will start a slippery slope of trying to satisfy
+everybody internally. Then things start looking more like Arch, with
+newbies scared off by the confusion. I know the Arch people like the
+power, but it took me several hours to figure out how to create a
+repository ;). Some people like bug dependencies, and some do not
+ e.g.
+ https://bugs.launchpad.net/malone/+bug/95419
+ http://trac.edgewall.org/ticket/31
+
+From the *long* Trac post, you can see that this is divisive issue.
+
+I would be in favor of emulating TracCrossReferences
+(http://trac.edgewall.org/wiki/TracCrossReferences) in our core. We
+could have references and backlinks fields for bugs (and comments?).
+But I'd rather not add blocking, etc. However, having a seperate
+plugin obviously doesn't work for some people ;). We'd like to bundle
+lots of functionality, but keep the core fairly clean and flexible.
+
+Therefore, I'd like a way to put non-core implememtation code in a
+seperate submod. We already call our libbe code "plugins", and we're
+extending the builtin BugDir, Bug, etc code, so I thought we'd call
+the non-core submods mixins (see http://en.wikipedia.org/wiki/Mixin).
+
+Anyhow, just my 2c.
+
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 20:42:12 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
+
+In-reply-to: ec133a4e-c9ff-4499-b469-cb0a2ca9a685
+
--- /dev/null
+This could be implemented with an external frontend storing the
+dependency data in arbitrary tags.
+
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 21:29:13 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
+
+In-reply-to: f87fd684-6af1-498d-98d5-f915bcee76a9
+
--- /dev/null
+In Aaron's Tue, 25 Nov 2008 09:32:29 -0500 email:
+
+>> 7ec:om: Arbitrary tags
+>> Sensible
+>
+> Implemented as a free-form value field similar to target? A
+> comma-seperated list of tags?
+
+I believe I planned to store it as an alpha-sorted, one-entry-per-line
+list, so it would support merging easily.
+
+> Perhaps once we have per-bug/comment
+> attribute searching it would be easier to have a 'create-attribute'
+> becommand, e.g.
+> be create-attribute [-valid=X,Y,Z] [bugdir|bug|comment] [NAME] [DEFAULT]
+
+Well, it really depends how much semantics you want to embed in the data
+format. Some values are scalars, some may be sets (i.e. tags), some may
+be ordered lists or even mappings. How much you want to reflect that in
+the data format is up to you.
+
+> Extend and make more consitent the settings_property() attributes.
+> Create becommand/(create/remove)-attribute for logic-less attributes.
+> Create a few mix-ins for logic-ed attributes
+
+I don't find the term mix-in very intuitive here.
+
+> Usage example:
+> Goal:
+> set up for `be depends BUGA BUGB`, `be depends --tree BUGA`, etc
+> Procedure:
+> be set --apend mixins bug:dependency
+
+"append" usually has two "p"s. Is the omission deliberate?
+
+> Where we've defined
+> becommands/depends.py, but it is hidden until the mixin is activated
+> libbe/mixins/bug/dependency.Mixin (inheriting from BugMixin)
+> to
+> parse/generate comma seperated dependency uuids for saving/loading
+> pretty-print the dependency list (e.g. uuid->shortname)
+> walk the dependency tree and check target bug status.
+>
+> With more complicated mixins, there could be inter-mixin dependencies,
+> e.g. a dependency tracker that searches depends based on bug.status
+> might depend on the base dependency mixin. This way people who need
+> it could make rich interfaces without confusing the people who don't.
+>
+> How does that sound?
+
+It sounds pretty complicated. I would probably use a type system rather
+than "mixins", and define types as "scalar", "set" and maybe "list" and
+"map". Dependencies would be a set, and their special behaviour would
+be hardcoded according to their name, not a property of their type.
+
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 20:40:54 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
+
+In-reply-to: 401950a0-a5ff-46f3-afac-a9cfb300f94b
+
--- /dev/null
+Merged from bug 17921fbc-e7f0-4f31-8cdd-598e5ba7237b
\ No newline at end of file
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 21:29:32 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
+creator: abentley
+severity: minor
-creator=abentley
+status: open
+summary: Arbitrary tags
-
-severity=minor
-
-
-
-
-
-
-status=open
-
-
-
-
-
-
-summary=Arbitrary tags
-
-
-
-
-
-
-time=Wed, 04 Jan 2006 21:06:38 +0000
-
-
+time: Wed, 04 Jan 2006 21:06:38 +0000
--- /dev/null
+No need for RCS-expansion for the history. If the user is versioning
+their code with some RCS, they presumably know how to use the RCS to
+investigate the history already. The .be/ directory structure is not
+so complicated that it's worth much work to avoid their having to peer
+inside it by hand.
+
+In rare cases where people really do want to peer into history using
+only BE or sort by e.g. bug closing time, they could add those
+comments by hand, e.g.
+ $ echo 'bug closed' | be comment <bug> -
+ $ be close <bug>
+So the already-implemented cmp_last_modified would handle it.
+
+If you want, you could add (optional) comment-generation to the
+becommands themselves. For example becommand/merge.py already does
+this.
+
--- /dev/null
+Content-type: text/plain
+
+
+Date: Mon, 22 Jun 2009 21:12:00 +0000
+
+
+From: W. Trevor King <wking@drexel.edu>
+
+
+In-reply-to: d81d0df9-e6d9-4fe8-8dbe-989ef2c81f00
+
severity: minor
-status: open
+status: closed
summary: Add last-modified field to bugs
projects / be.git / commitdiff