On Sun, May 01, 2011 at 02:52:13AM +0200, Christian Heinrich wrote: > However, it really took me a while to get going:
Sorry. Hopefully the packaging gets better soon!
> After some searching I found out that I had to use "make DOC= install"
This is mentioned in doc/install.txt.
> calling "be" just told me that the class "libbe.ui.command_line.py"
> could not be imported. I had to investigate that there's a
> PYTHONPATH variable that I could set to the appropriate path, in my
> case
>
> export PYTHONPATH=/home/heinrich/lib/python2.7/site-packages/
This should be fixed in my branch since
Author: W. Trevor King <[email protected]>
AuthorDate: Sat Apr 16 21:26:02 2011 -0400
Fix /64c by installing with `--user` by default (vs. --prefix=${HOME}).
This way users don't need to mess with PYTHONPATH. They'll still need
to tweak PATH so they can find the be entry script.
It should probably be merged into the trunk (<bumps Chris>).
> 1.) 4a4:os Is a good point. The reason for including something like
> "medium" or "normal" is that I want to differentiate between e.g. a
> typo, which really is a minor bug, and lets say an if-condition that
> always evaluates to false. (You know what I mean..)
You can customize statuses and severities by configuring the bug
repository. For example, the stock BE bug repository adds a
"disabled" status (in
.be/bea86499-824e-4e77-b085-2d581fa9ccab/settings) since some older
bugs had that status. You can add your medium severity with something
like
severities:
- - target
- The issue is a target or milestone, not a bug.
- - wishlist
- A feature that could improve usefulness, but not a bug.
- - minor
- Typos and other insignificant bugs.
- - medium
- The standard bug level.
- - serious
- A bug that requires workarounds.
- - critical
- A bug that prevents some features from working at all.
- - fatal
- A bug that makes the package unusable.
In your repository's settings file. You should be able to configure
this through `be set severities VALUE`, but I haven't been able to
think of a reasonable syntax for lists of tuples. For now you'll have
to edit the settings file directly.
Another problem with the current implementation is that the default
bug severity is hardcoded to `minor`. This would be easy enough to
customize as a BugDir-wide setting. I'll add it sometime in the next
week, once I get enough free time.
> 2.) The overview created by "be list" could be slightly improved. It
> might look like this:
> ---------------------------------------------------------------------
> ID | TYPE | TITLE | SEVERITY
> ---------------------------------------------------------------------
> 1 | BUG | Missing file doc comment | CRITICAL
> 2 | TO-DO | Missing class doc comment | Future
> 3 | TASK | Foo | NORMAL
> ---------------------------------------------------------------------
>
> I believe that this is really nice and it shouldn't be too much work. I
> could try and implement it myself, if you wish. However, I really don't
> know much of python :)
This is certainly possible, by `TYPE` do you mean `severity`?
Currently `target`s are a severity, and all the other severities are
bundled together.
The current format has been tuned to be as compact as possible, so
only bugs with really long summaries will wrap in a standard
80-char-wide terminal. Being more verbose will make the acceptable
summary length shorter, and it can be hard to be that succinct.
> By the way, I would like to differentiate between "Bug Description" and
> "Bug Title". The Bug title should be a short description (say, < 50
> chars)
The current `summary` fills the role of bug title. If you feel that
more detailed description is needed, you can always add a comment. I
don't see how your "bug description" would differ from that comment.
> 3.) Using wrong syntax should receive better help messages.
> ...
How about:
"be new" -> ERROR:
Missing required argument SUMMARY
Run `be help new` for usage details
Most of the times I mistype commands it's silly, and I only want a
short reminder. For newer users, the full help details may be
interesting, so I'm fine with pointing towards them, but they are too
long to print every time.
Chopping the description would help somewhat, but some commands have a
full screen of options (e.g. `be list`).
> 4.) "be show" should also list the "target" just as "tags"
I don't understand what you mean here. Can you give an explicit
example? I don't think `be show` shows either targets, tags, or any
extra_string values. It should though, and as a stop-gap solution we
could just print the strings.
> 5.) Interesting: The ID (the long hash) displayed with "be show" is
> *NOT* the BUG-ID, which actually is the "short name". Maybe change the
> name? Confused me a lot!
Ah. That is a good point. The long hash *is* the bug ID, but when
commands ask for bug IDs, they actually want a compound
BUGDIR-ID/BUG-ID[/COMMENT-ID]. There should be links from the
relevant sections of the tutorial to libbe.util.id:
http://www.physics.drexel.edu/~wking/code/be/doc/libbe/libbe.util.id.html
But I seem to have borked the Sphinx cross referencing. I'll try
and make this clearer.
> 6.) "be help" displays weird description for command "be serve"
Hehe. Yes. Fixed in my branch now. I need to reread PEP-257 ;).
> 7.) Might be some more work, but
>
> 7.1) Integrate a log for changes to a bug. Could be implemented as
> additional comments, like: "<date> Severity changed to CRITICAL by
> <user>"
This is on my distant todo list. The best we have at the moment is
`be diff`. Ideally, we'd like a BE interface to something like
git log --follow .be/bea*/bugs/64c*/
but adding that for all our supported versioning backends will take
some time.
> 7.2) Create a "be vote BUG-ID +|-" command. You can vote on bugs either
> pro (+) or against (-) it.
I'm not convinced this is generally useful enough to hard-code in.
Perhaps an extra_string-based approach (like `be tag`) with a list of
(symbol, voter) tuples? That would be fairly easy to write, with
results that just printed the tuples:
$ be vote BUG-ID
+ John Doe <[email protected]>
+ ...
- ...
- ...
> I would really appreciate if you could comment on my suggestions.
Thanks for your feedback. BE works well for us, so it's good to have
fresh ideas to keep pushing things along ;).
> If you like, I will try to implement some of the changes myself -
> always wanted to dig into python.
I can point you in useful directions if you have something that you
think looks accessible. 7.2 is probably your best bet. Create
libbe/command/vote.py, looking for inspiration to libbe/command/tag.py
and libbe/command/subscribe.py. Feel free to pitch in anywhere you
like, though ;).
--
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
pgpOtZ4brmVrC.pgp
Description: PGP signature
_______________________________________________ Be-devel mailing list [email protected] http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
