--- /dev/null
+> It would be nice if we could store tests.
+> .be/BUGDIR/tests/...
+> and link them from bugs.
+
+Better: have them be comments with a TEST tag.
+
+The mime type could hint at the execution mechanism:
+ text/x-python
+ application/x-sh
+ ...
+
+> Then running
+> test.py BUGDIR/BUG
+> would run the tests for that particular bug.
+>
+> This would provide regression testing via
+> test.py $(be list --ids --status fixed)
+
+This should be a 'test' command (libbe.command.test.Test), since
+people will want to test bugs for their own projects, and out current
+test.py is for testing BE specifically. It should be
+ be test BUGDIR/BUG
+ be test $(be list --ids --status fixed)
+
+We _should_ add be
+ test $(be list --ids --status fixed)
+to test.py for regression testing.
+
+This whole thing would make the fixed/closed distinction more clear,
+since fixed bugs would get tests run and expect success, while closed
+bugs' tests would be skipped.
+
+Finally, if users are submitting tests on their own, it would be a
+good idea to sandbox them, but a portable way for sandboxing scripts
+sounds very complicated. It would probably be easier to sandbox
+python scripts, but I don't know what that would look like...
+
+A work around would be to allow users to post tests, but not allow
+them to set the TEST flag. Then the bugdir maintainer could set the
+flag themselves once they'd vetted the test. Much uglier than
+sandboxing, but also much more easily implemented.
+
--- /dev/null
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 31 Jan 2010 17:36:52 +0000
+
+
+In-reply-to: ba96f1c0-ba48-4df8-aaf0-4e3a3144fc46
+
--- /dev/null
+Either of these could be added at the
+ libbe.command.base.Command.run
+level.
+
+The Git hooks would be 'pre-<command-name>' and 'post-<command-name>'.
+
+Oh, and the hooks are therefore command-level hooks, not storage-level
+hooks. We still want storage-level hooks for notification emails, etc,
+and they would definately have to follow the Git directory approach.
+Hmm. Storage level hooks will be awkward...
+
--- /dev/null
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 31 Jan 2010 18:04:49 +0000
+
+
+In-reply-to: f3e90a7e-b8c4-4a7c-8609-6a783ae59762
+
--- /dev/null
+Before Bugs Everywhere Directory v1.4 we kept
+ "encoding"
+ "vcs_name"
+and other bugdir-wide configuration options in ./be/settings
+
+Now we don't store them anymore, but we should keep some. For
+example, the encoding setting is useful when running `be html` in a
+cron job. The settings are repository wide, so they should _still_ go
+in ./be/settings (since there may, eventually, be several bugdirs in a
+repo), but who's job is it to read that file?
+
+The user interface takes care of encoding, but the storage object
+would be checking for a bug repository and reading the settings file.
+How/when does it notify the UI?
+
--- /dev/null
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 01 Feb 2010 14:34:10 +0000
+
--- /dev/null
+On the other hand, since encoding decisions seem to be locale-driven,
+so you can just setup the appropriate locale environmental variables
+in your cron job:
+ export LANG=en_US.utf8
+and that should do it...
--- /dev/null
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 01 Feb 2010 15:35:57 +0000
+
+
+In-reply-to: 2cd562f5-fcb9-4cc5-bf8c-ad5c9d960761
+
--- /dev/null
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: W. Trevor King <wking@drexel.edu>
+
+
+severity: minor
+
+
+status: open
+
+
+summary: Where should the vcs-name and encoding configuration options live?
+
+
+time: Mon, 01 Feb 2010 14:28:13 +0000
+
ret = ui.run(command, options, args)
except CallbackExit:
return 0
+ except UnicodeDecodeError, e:
+ print >> ui.io.stdout, '\n'.join([
+ 'ERROR:', str(e),
+ 'You should set a locale that supports unicode, e.g.',
+ ' export LANG=en_US.utf8',
+ 'See http://docs.python.org/library/locale.html for details',
+ ])
+ return 1
except libbe.command.UserError, e:
print >> ui.io.stdout, 'ERROR:\n', e
return 1