--- /dev/null
+Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+
+> the basic idea is to take a look at all public branches (for exaple
+> all on lp/bitbucket/github) in order to tell the user of a
+> webinterface that bug foo is fixed in branch xyz, and if its merged to
+> the main branch
+
+I don't understand. The state of the bug in the main branch is right
+there in the main branch; if it's not fixed there, it's not fixed there.
+If it's merged in from a different branch, the bug state follows all the
+other changes when they come in.
+
+Can you give an example of what would be done differently?
+
+--
+ \ “The basic fact about human existence is not that it is a |
+ `\ tragedy, but that it is a bore.” —Henry L. Mencken |
+_o__) |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <874otjmjhr.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 23:34:08 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
--- /dev/null
+On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> 1. is there any way to aggregate over multiple public branches in order
+> to get the complete bug state
+
+Keeping the bug data with the source helps synchronize bug state and
+source code. Bug state in branch A may not apply to branch B. Some
+people like to weaken this source-bug linkage by keeping their bugs in
+a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+currently supports this workflow). It sounds like you want to move
+from "bugs with code" to "bugs and code in separate branches". We
+don't have an easy way to do that in BE at the moment, since
+version-control systems like Git have a single working branch at a
+time (I think :p). What VCS are you using as a backend?
+
+> 2. is there any model for storing bigger files at a central place (for
+> some of my bugs i have multi-megabyte tarballs attached)
+
+ be comment ID "See the tarball at http://yourpage/something.tar.gz"
+Then to grab the tarball, you'd use:
+ wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+to grab it.
+
+--
+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
--- /dev/null
+Alt-id: <20090711125030.GA18185@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 08:50:30 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
--- /dev/null
+Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+
+> 1. is there any way to aggregate over multiple public branches in
+> order to get the complete bug state
+
+The bug state is as complete as the source code state. It's exactly as
+aggregated as the rest of the source code; the “complete bug state”
+would be the integration branch where you merge all the feature branches
+and bug-fix branches together.
+
+If instead you want bugs to *not* be tightly linked with the rest of the
+source code state, it seems you don't want a distributed bug tracker
+like Bugs Everywhere.
+
+--
+ \ “I cannot conceive that anybody will require multiplications at |
+ `\ the rate of 40,000 or even 4,000 per hour …” —F. H. Wales, 1936 |
+_o__) |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <878wivmjm1.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 23:31:34 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
--- /dev/null
+On Mon, Jul 13, 2009 at 09:05:34AM +0200, Ronny Pfannschmidt wrote:
+> On Sun, 2009-07-12 at 19:55 -0400, W. Trevor King wrote:
+> > On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
+> > > On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> > > > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > > > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > > > > 2. is there any model for storing bigger files at a central place (for
+> > > > > > > some of my bugs i have multi-megabyte tarballs attached)
+> > > > > >
+> > > > > > be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > > > > Then to grab the tarball, you'd use:
+> > > > > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > > > > to grab it.
+> > > > >
+> > > > > so the basic idea is to do it completely self-managed
+> > > > > and have have heterogenous sources of extended data?
+> > > >
+> > > > I assume "extended data" here refers to your tarballs. What sort of
+> > > > homogenous source did you have in mind? The comment body is currently
+> > > > just a binary blob for non-text/* types, otherwise it's text in
+> > > > whatever encoding you've configured.
+> > >
+> > > some kind of common upload target for a single project in order to have
+> > > more reliable sources of stuff thats related to bugs but doesnt fit into
+> > > the normal repository
+> >
+> > Sorry, I'm still having trouble with "doesn't fit into the normal
+> > repository". It's going to be large wherever you keep it. You
+> > worried about multiple branches all having these big tarballs in them
+> > and want a "lightweight" checkout without all the big
+> > tarballs/whatever? I still think having some sort of "resources"
+> > directory on an http server somewhere that you link to from comments
+> > is the best plan. If you use the
+> > be show --xml ID | be-xml-to-mbox | catmutt
+> > approach, you can even write your comments in text/html and get
+> > clickable links ;). A "push big file to remote and commit comment
+> > linking to it" script would be pretty simple and keep everything
+> > consistent.
+>
+> thats probably what i want to do
+
+#!/bin/bash
+REMOTE_DIR="you@webhost:./public_html/bigfiles"
+REMOTE_LINK="http://www.webhost.com/bigfiles"
+if [ $# -ne 2 ]; then
+ echo "usage: $0 ID BIGFILE"
+ exit 1
+fi
+ID="$1"
+BIGFILE="$2"
+be comment "$ID" "Large file stored at ${REMOTE_LINK}/${BIGFILE}" && scp "$BIGFILE" "${REMOTE_DIR}"
+
+> > > > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > > > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> > > > >
+> > > > > > i want to see the combination of the bug data of all branches
+> > > > >
+> > > > > How is a tool to determine the set of “all branches”? The distributed
+> > > > > VCS model means that set is indeterminate.
+> > > >
+> > > > He could just make a list of branches he likes.
+> > > >
+> > > > Ronny, are you looking to check bug status across several repos on the
+> > > > fly, or periodically run something (with cron, etc.) to update a
+> > > > static multi-repo summary?
+> > >
+> > > on the fly access
+> >
+> > Then listing bugs in a remote repo will either involve httping tons of
+> > tiny values files for each bug (slow?) or running some hypothetical
+> > BE-server locally for each repo speaking some BE-specific protocol
+> > (complicated?). And how would you handle e.g. headless git repos,
+> > where nothing's even checked out?
+> >
+> > You could always run the cron job every 15 minutes, and rely on
+> > whatever VCS you're using having some intelligent protocol/procedure
+> > to keep bandwidth down ;). If you need faster / more-efficient
+> > updates, you'll probably need to throw out polling altogether and
+> > setup all involved repos with a "push to central-repo on commit" hook
+> > or some such.
+>
+> its intended to run on the place where i publish the repositories anyway
+
+Oh, you mean all the repos you want to cover are all _already_ on the
+same host?
+
+--
+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
--- /dev/null
+Alt-id: <20090713104715.GA13723@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 06:47:15 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 6dcc910a-ce15-4eeb-b49b-4747719748ed
+
--- /dev/null
+On Sat, Jul 11, 2009 at 11:25:07AM -0400, W. Trevor King wrote:
+> The easiest implementation I can think of would be to keep local
+> branches (on whatever computer is hosting your web interface)
+> following your favorite repos.
+> proxectX/
+> |-- repoA
+> |-- repoB
+> `-- repoC
+> You'd pull upstream changes with a cron job.
+> Listing bugs would be something along the lines of
+> projectX$ for repo in *
+> do
+> pushd $repo
+> be list
+> popd
+> done | sort | uniq
+> ...
+
+I've reworked option handling for be, so my branch now supports
+ projectX$ for repo in *
+ do
+ be --dir $repo list
+ done | sort | uniq
+etc. This also makes it easy to use your uninstalled development
+version of be on any bug directory on your local machine.
+
+--
+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
--- /dev/null
+Alt-id: <20090713115734.GA13788@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 07:57:34 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40
+
--- /dev/null
+On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
+> On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > > 2. is there any model for storing bigger files at a central place (for
+> > > > > some of my bugs i have multi-megabyte tarballs attached)
+> > > >
+> > > > be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > > Then to grab the tarball, you'd use:
+> > > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > > to grab it.
+> > >
+> > > so the basic idea is to do it completely self-managed
+> > > and have have heterogenous sources of extended data?
+> >
+> > I assume "extended data" here refers to your tarballs. What sort of
+> > homogenous source did you have in mind? The comment body is currently
+> > just a binary blob for non-text/* types, otherwise it's text in
+> > whatever encoding you've configured.
+>
+> some kind of common upload target for a single project in order to have
+> more reliable sources of stuff thats related to bugs but doesnt fit into
+> the normal repository
+
+Sorry, I'm still having trouble with "doesn't fit into the normal
+repository". It's going to be large wherever you keep it. You
+worried about multiple branches all having these big tarballs in them
+and want a "lightweight" checkout without all the big
+tarballs/whatever? I still think having some sort of "resources"
+directory on an http server somewhere that you link to from comments
+is the best plan. If you use the
+ be show --xml ID | be-xml-to-mbox | catmutt
+approach, you can even write your comments in text/html and get
+clickable links ;). A "push big file to remote and commit comment
+linking to it" script would be pretty simple and keep everything
+consistent.
+
+> > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> > >
+> > > > i want to see the combination of the bug data of all branches
+> > >
+> > > How is a tool to determine the set of “all branches”? The distributed
+> > > VCS model means that set is indeterminate.
+> >
+> > He could just make a list of branches he likes.
+> >
+> > Ronny, are you looking to check bug status across several repos on the
+> > fly, or periodically run something (with cron, etc.) to update a
+> > static multi-repo summary?
+>
+> on the fly access
+
+Then listing bugs in a remote repo will either involve httping tons of
+tiny values files for each bug (slow?) or running some hypothetical
+BE-server locally for each repo speaking some BE-specific protocol
+(complicated?). And how would you handle e.g. headless git repos,
+where nothing's even checked out?
+
+You could always run the cron job every 15 minutes, and rely on
+whatever VCS you're using having some intelligent protocol/procedure
+to keep bandwidth down ;). If you need faster / more-efficient
+updates, you'll probably need to throw out polling altogether and
+setup all involved repos with a "push to central-repo on commit" hook
+or some such.
+
+--
+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
--- /dev/null
+Alt-id: <20090712235502.GA10782@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 12 Jul 2009 19:55:02 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 8ffc90d7-0be7-4b00-88e6-9ae1b65f7957
+
--- /dev/null
+On Sun, 2009-07-12 at 19:55 -0400, W. Trevor King wrote:
+> On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
+> > On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> > > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > > > 2. is there any model for storing bigger files at a central place (for
+> > > > > > some of my bugs i have multi-megabyte tarballs attached)
+> > > > >
+> > > > > be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > > > Then to grab the tarball, you'd use:
+> > > > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > > > to grab it.
+> > > >
+> > > > so the basic idea is to do it completely self-managed
+> > > > and have have heterogenous sources of extended data?
+> > >
+> > > I assume "extended data" here refers to your tarballs. What sort of
+> > > homogenous source did you have in mind? The comment body is currently
+> > > just a binary blob for non-text/* types, otherwise it's text in
+> > > whatever encoding you've configured.
+> >
+> > some kind of common upload target for a single project in order to have
+> > more reliable sources of stuff thats related to bugs but doesnt fit into
+> > the normal repository
+>
+> Sorry, I'm still having trouble with "doesn't fit into the normal
+> repository". It's going to be large wherever you keep it. You
+> worried about multiple branches all having these big tarballs in them
+> and want a "lightweight" checkout without all the big
+> tarballs/whatever? I still think having some sort of "resources"
+> directory on an http server somewhere that you link to from comments
+> is the best plan. If you use the
+> be show --xml ID | be-xml-to-mbox | catmutt
+> approach, you can even write your comments in text/html and get
+> clickable links ;). A "push big file to remote and commit comment
+> linking to it" script would be pretty simple and keep everything
+> consistent.
+thats probably what i want to do
+
+>
+> > > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> > > >
+> > > > > i want to see the combination of the bug data of all branches
+> > > >
+> > > > How is a tool to determine the set of “all branches”? The distributed
+> > > > VCS model means that set is indeterminate.
+> > >
+> > > He could just make a list of branches he likes.
+> > >
+> > > Ronny, are you looking to check bug status across several repos on the
+> > > fly, or periodically run something (with cron, etc.) to update a
+> > > static multi-repo summary?
+> >
+> > on the fly access
+>
+> Then listing bugs in a remote repo will either involve httping tons of
+> tiny values files for each bug (slow?) or running some hypothetical
+> BE-server locally for each repo speaking some BE-specific protocol
+> (complicated?). And how would you handle e.g. headless git repos,
+> where nothing's even checked out?
+>
+> You could always run the cron job every 15 minutes, and rely on
+> whatever VCS you're using having some intelligent protocol/procedure
+> to keep bandwidth down ;). If you need faster / more-efficient
+> updates, you'll probably need to throw out polling altogether and
+> setup all involved repos with a "push to central-repo on commit" hook
+> or some such.
+its intended to run on the place where i publish the repositories anyway
--- /dev/null
+Alt-id: <1247468734.7189.1.camel@localhost>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 09:05:34 +0200
+
+
+From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+In-reply-to: 4d192c6c-a4a8-4844-b083-2dd5926bd2d9
+
--- /dev/null
+Hi,
+
+1. is there any way to aggregate over multiple public branches in order
+to get the complete bug state
+
+2. is there any model for storing bigger files at a central place (for
+some of my bugs i have multi-megabyte tarballs attached)
+
+Regards Ronny
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <1247313294.7701.60.camel@localhost>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 13:54:54 +0200
+
+
+From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
--- /dev/null
+On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > 1. is there any way to aggregate over multiple public branches in order
+> > > > to get the complete bug state
+> > >
+> > > Keeping the bug data with the source helps synchronize bug state and
+> > > source code. Bug state in branch A may not apply to branch B. Some
+> > > people like to weaken this source-bug linkage by keeping their bugs in
+> > > a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+> > > currently supports this workflow). It sounds like you want to move
+> > > from "bugs with code" to "bugs and code in separate branches". We
+> > > don't have an easy way to do that in BE at the moment, since
+> > > version-control systems like Git have a single working branch at a
+> > > time (I think :p). What VCS are you using as a backend?
+> >
+> > the basic idea is to take a look at all public branches (for exaple all
+> > on lp/bitbucket/github) in order to tell the user of a webinterface that
+> > bug foo is fixed in branch xyz, and if its merged to the main branch
+>
+> Hmm.
+>
+> > > > 2. is there any model for storing bigger files at a central place (for
+> > > > some of my bugs i have multi-megabyte tarballs attached)
+> > >
+> > > be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > Then to grab the tarball, you'd use:
+> > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > to grab it.
+> > so the basic idea is to do it completely self-managed
+>
+> Well, it's going to be managed by somebody ;). So far I'm not
+> convinced enough for the manager to be me, so I'm suggesting it be you
+> :p.
+>
+> > and have have heterogenous sources of extended data?
+>
+> I assume "extended data" here refers to your tarballs. What sort of
+> homogenous source did you have in mind? The comment body is currently
+> just a binary blob for non-text/* types, otherwise it's text in
+> whatever encoding you've configured.
+some kind of common upload target for a single project in order to have
+more reliable sources of stuff thats related to bugs but doesnt fit into
+the normal repository
+
+
+>
+> On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> >
+> > > i want to see the combination of the bug data of all branches
+> >
+> > How is a tool to determine the set of “all branches”? The distributed
+> > VCS model means that set is indeterminate.
+>
+> He could just make a list of branches he likes.
+>
+> Ronny, are you looking to check bug status across several repos on the
+> fly, or periodically run something (with cron, etc.) to update a
+> static multi-repo summary?
+on the fly access
+
+>
+> The easiest implementation I can think of would be to keep local
+> branches (on whatever computer is hosting your web interface)
+> following your favorite repos.
+> proxectX/
+> |-- repoA
+> |-- repoB
+> `-- repoC
+> You'd pull upstream changes with a cron job.
+> Listing bugs would be something along the lines of
+> projectX$ for repo in *
+> do
+> pushd $repo
+> be list
+> popd
+> done | sort | uniq
+> Then to show bug status you would have something like
+> projectX$ for repo in *
+> do
+> echo $repo
+> pushd $repo
+> be show ${BUGID}
+> popd
+> done
+> For a web frontend, you'd want to translate that to python/libbe.
+>
+
+yes, the idea is to get a web fontend for multiple branches
+and maybe a local gtk fontend for local multi-branch setups
+
+for some of my projects i have n local and m remote repos, and merging
+is not always intended soonish
--- /dev/null
+Alt-id: <1247433610.14803.3.camel@localhost>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 12 Jul 2009 23:20:10 +0200
+
+
+From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40
+
--- /dev/null
+On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > 1. is there any way to aggregate over multiple public branches in order
+> > > to get the complete bug state
+> >
+> > Keeping the bug data with the source helps synchronize bug state and
+> > source code. Bug state in branch A may not apply to branch B. Some
+> > people like to weaken this source-bug linkage by keeping their bugs in
+> > a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+> > currently supports this workflow). It sounds like you want to move
+> > from "bugs with code" to "bugs and code in separate branches". We
+> > don't have an easy way to do that in BE at the moment, since
+> > version-control systems like Git have a single working branch at a
+> > time (I think :p). What VCS are you using as a backend?
+>
+> the basic idea is to take a look at all public branches (for exaple all
+> on lp/bitbucket/github) in order to tell the user of a webinterface that
+> bug foo is fixed in branch xyz, and if its merged to the main branch
+
+Hmm.
+
+> > > 2. is there any model for storing bigger files at a central place (for
+> > > some of my bugs i have multi-megabyte tarballs attached)
+> >
+> > be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > Then to grab the tarball, you'd use:
+> > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > to grab it.
+> so the basic idea is to do it completely self-managed
+
+Well, it's going to be managed by somebody ;). So far I'm not
+convinced enough for the manager to be me, so I'm suggesting it be you
+:p.
+
+> and have have heterogenous sources of extended data?
+
+I assume "extended data" here refers to your tarballs. What sort of
+homogenous source did you have in mind? The comment body is currently
+just a binary blob for non-text/* types, otherwise it's text in
+whatever encoding you've configured.
+
+On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+>
+> > i want to see the combination of the bug data of all branches
+>
+> How is a tool to determine the set of “all branches”? The distributed
+> VCS model means that set is indeterminate.
+
+He could just make a list of branches he likes.
+
+Ronny, are you looking to check bug status across several repos on the
+fly, or periodically run something (with cron, etc.) to update a
+static multi-repo summary?
+
+The easiest implementation I can think of would be to keep local
+branches (on whatever computer is hosting your web interface)
+following your favorite repos.
+ proxectX/
+ |-- repoA
+ |-- repoB
+ `-- repoC
+You'd pull upstream changes with a cron job.
+Listing bugs would be something along the lines of
+ projectX$ for repo in *
+ do
+ pushd $repo
+ be list
+ popd
+ done | sort | uniq
+Then to show bug status you would have something like
+ projectX$ for repo in *
+ do
+ echo $repo
+ pushd $repo
+ be show ${BUGID}
+ popd
+ done
+For a web frontend, you'd want to translate that to python/libbe.
+
+--
+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
--- /dev/null
+Alt-id: <20090711152507.GA18461@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 11:25:07 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200
+
--- /dev/null
+On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+>
+> > i want to see the combination of the bug data of all branches
+>
+> What is your definition of ???all branches???? When I'm working with
+> distributed VCS, I create branches wherever I feel like, and the VCS
+> tool doesn't have some central registry of branches to keep up to date.
+>
+> How is a tool to determine the set of ???all branches???? The distributed
+> VCS model means that set is indeterminate.
+
+In the first main Ronny spoke about "public" branches. To me it means that
+if a branch is public, he should like to have a status of that branch.
+
+We all agree (probably ;-) ) that tha main branch is the "right" branch, but
+as I see it, Ronny's question has some logic.
+I'd like to know that a certain bug is fixed in a certain branch, also if it
+is still not merged in the main branch, for various reason (ie I am interested
+in the solution since the bug stop my work)
+
+Imagine it like a rss feed aggregator: in one place there are all the bugs of
+all the branches that the developers make avaible to the public with
+a repository. This can make easier the life to who want to try a something
+since he know what branch he must check out, instead of checking all the
+branch he can find to test if he get what is looking for.
+
+Unluckyly I have no idea how to solve it. :-(
+
+bye
+Gianluca
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <20090713085859.GA21800@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 10:58:59 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200
+
--- /dev/null
+On Sat, 2009-07-11 at 23:34 +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+>
+> > the basic idea is to take a look at all public branches (for exaple
+> > all on lp/bitbucket/github) in order to tell the user of a
+> > webinterface that bug foo is fixed in branch xyz, and if its merged to
+> > the main branch
+>
+> I don't understand. The state of the bug in the main branch is right
+> there in the main branch; if it's not fixed there, it's not fixed there.
+> If it's merged in from a different branch, the bug state follows all the
+> other changes when they come in.
+>
+> Can you give an example of what would be done differently?
+>
+i want to see the combination of the bug data of all branches
+
+for example
+
+i got bug
+its fixed in the branch "something"
+its not fixed/merged to "main"
+
+now something like a website should tell me, this bug has been fixed in
+branch xyz and the fix is not yet merged into main
+
+
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <1247320857.7701.67.camel@localhost>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 16:00:57 +0200
+
+
+From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+In-reply-to: 0f60a148-7024-44bd-bbed-377cbece9d1b
+
--- /dev/null
+On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > 1. is there any way to aggregate over multiple public branches in order
+> > to get the complete bug state
+>
+> Keeping the bug data with the source helps synchronize bug state and
+> source code. Bug state in branch A may not apply to branch B. Some
+> people like to weaken this source-bug linkage by keeping their bugs in
+> a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+> currently supports this workflow). It sounds like you want to move
+> from "bugs with code" to "bugs and code in separate branches". We
+> don't have an easy way to do that in BE at the moment, since
+> version-control systems like Git have a single working branch at a
+> time (I think :p). What VCS are you using as a backend?
+the basic idea is to take a look at all public branches (for exaple all
+on lp/bitbucket/github) in order to tell the user of a webinterface that
+bug foo is fixed in branch xyz, and if its merged to the main branch
+>
+> > 2. is there any model for storing bigger files at a central place (for
+> > some of my bugs i have multi-megabyte tarballs attached)
+>
+> be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> Then to grab the tarball, you'd use:
+> wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> to grab it.
+so the basic idea is to do it completely self-managed and have have
+heterogenous sources of extended data?
--- /dev/null
+Alt-id: <1247317985.7701.63.camel@localhost>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 11 Jul 2009 15:13:05 +0200
+
+
+From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+In-reply-to: 13012b22-2d02-444c-87c0-8cf0f17137ae
+
--- /dev/null
+Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+
+> i want to see the combination of the bug data of all branches
+
+What is your definition of “all branches”? When I'm working with
+distributed VCS, I create branches wherever I feel like, and the VCS
+tool doesn't have some central registry of branches to keep up to date.
+
+How is a tool to determine the set of “all branches”? The distributed
+VCS model means that set is indeterminate.
+
+--
+ \ “Pinky, are you pondering what I'm pondering?” “I think so, |
+ `\ Brain, but I find scratching just makes it worse.” —_Pinky and |
+_o__) The Brain_ |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <87zlbbl128.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 12 Jul 2009 00:57:35 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7
+
--- /dev/null
+On Sat, Jul 11, 2009 at 11:31:34PM +1000, Ben Finney wrote:
+> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+>
+> > 1. is there any way to aggregate over multiple public branches in
+> > order to get the complete bug state
+>
+> The bug state is as complete as the source code state. It's exactly as
+> aggregated as the rest of the source code; the ???complete bug state???
+> would be the integration branch where you merge all the feature branches
+> and bug-fix branches together.
+>
+> If instead you want bugs to *not* be tightly linked with the rest of the
+> source code state, it seems you don't want a distributed bug tracker
+> like Bugs Everywhere.
+
+"the complete bug state" probably means that he want to know (and in some way
+to publish it) that the bug "xyz" is fixed and merged in main while bug "abc"
+is fixed but only in branch "123" and bug "def" is still open in branch "456"
+
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <20090713090341.GB21800@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 13 Jul 2009 11:03:41 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: 1f9f60de-ba37-42bc-a1c0-dc062ef255e1
+
--- /dev/null
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
+
+
+severity: wishlist
+
+
+status: unconfirmed
+
+
+summary: Bug aggregation. Multi-repo meta-BE?
+
+
+time: Tue, 21 Jul 2009 18:32:12 +0000
+
--- /dev/null
+On Sunday 19 July 2009 00:00:46 Chris Ball wrote:
+> Hi,
+>
+> > For example, let's assume we have target a, b, c There is a way
+> > to know that "a" is a past target, "b" is the current target and
+> > "c" is a future target ?
+>
+> We could add a "date due" field for each target.
+
+Good idea
+
+> > More: there is a way to know if a target is closed or open ?
+>
+> We could add a "target close" operation that moves all open bugs
+> assigned to one target to the next date-due target.
+
+Nice. But instead of moving all bugs to the next date-due target, I'd prefer
+to leave the choice to the user
+
+
+> I see problems with these ideas in general, because we're assuming
+> agreement by all parties/branches on when a target's date due is.
+> Maybe it's okay to demand that social conventions be used to handle
+> such a disagreement, or maybe not.
+
+I don't see these as problems per se. We can have two cases:
+
+1) a personal branch (like my html output or Trevor's email interface). In
+this case there is not any problem to decide the due date
+
+2) a branch with a group of delopers (let it be the canonical branch o an
+experimental branch): in this case I suppose that working together means to be
+able to agree on some things
+
+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
+
+bye
+Gianluca
+
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907202259.11774.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 20 Jul 2009 22:59:11 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: 6555a651-5a7f-4a8a-9793-47ad1315e9e8
+
--- /dev/null
+Hi,
+
+ > For example, let's assume we have target a, b, c There is a way
+ > to know that "a" is a past target, "b" is the current target and
+ > "c" is a future target ?
+
+We could add a "date due" field for each target.
+
+ > More: there is a way to know if a target is closed or open ?
+
+We could add a "target close" operation that moves all open bugs
+assigned to one target to the next date-due target.
+
+I see problems with these ideas in general, because we're assuming
+agreement by all parties/branches on when a target's date due is.
+Maybe it's okay to demand that social conventions be used to handle
+such a disagreement, or maybe not.
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <m3skgt648h.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 18:00:46 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: b9865d8b-46ae-4169-bc83-d75a98164729
+
--- /dev/null
+On Monday 20 July 2009 23:03:18 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?
+
+Ok. As soon as I finish a basic implementation of the html export, I will be
+glad to try to write a patch.
+
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907202340.39963.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 20 Jul 2009 23:40:39 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: 777182da-a216-45c7-bf4d-42c84e511c66
+
--- /dev/null
+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?
+
+Thanks,
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <m3hbx72hk9.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 20 Jul 2009 17:03:18 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: 4952e1c7-e035-42f1-882b-6b5264481d0a
+
--- /dev/null
+On Sat, Jul 18, 2009 at 06:00:46PM -0400, Chris Ball wrote:
+> > For example, let's assume we have target a, b, c There is a way
+> > to know that "a" is a past target, "b" is the current target and
+> > "c" is a future target ?
+>
+> We could add a "date due" field for each target.
+
+Another option would be a "blocked by" field, since you might miss
+deadlines, or have parallel targeted branches. Or just pick target
+names following some scheme so the alphanumeric-sort is also a
+dependency-order sort ;).
+
+> > More: there is a way to know if a target is closed or open ?
+
+There's also
+ $ be list --target 0.1
+If there are active bugs, the target is open. Otherwise, you must have
+made it ;).
+
+> We could add a "target close" operation that moves all open bugs
+> assigned to one target to the next date-due target.
+
+for bug in `be list --target 0.1 --uuids`; do
+ be target $bug $NEXT_TARGET
+done
+
+To avoid the loop, we could change status, severity, target, etc from
+ be COMMAND BUG ARG
+to
+ be COMMAND ARG BUG [MORE BUGS ...]
+
+--
+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
--- /dev/null
+Alt-id: <20090718222701.GA304@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 18:27:01 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 6555a651-5a7f-4a8a-9793-47ad1315e9e8
+
--- /dev/null
+Hello
+
+Just a question and only for curiosity: there is an easy way to determine the
+target succession ?
+
+For example, let's assume we have target a, b, c
+There is a way to know that "a" is a past target, "b" is the current target
+and "c" is a future target ? More: there is a way to know if a target is
+closed or open ?
+
+thanks
+
+bye
+Gianluca
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907182351.03217.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 23:51:03 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
--- /dev/null
+assigned: Gianluca Montecchi <gian@grys.it>
+
+
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: Gianluca Montecchi <gian@grys.it>
+
+
+severity: wishlist
+
+
+status: assigned
+
+
+summary: Sorting targets chronologically
+
+
+time: Tue, 21 Jul 2009 18:34:25 +0000
+
--- /dev/null
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote:
+> > Instead of a separate command for each output format, could we have
+> > a single "produce a static report of the bug database" command, and
+> > specify output format as an option?
+> > […]
+>
+> Do people like this architecture better than my be-xml-to-mbox
+> approach?
+
+I think this question is illuminated by the related question: Is mbox
+output a static report, or another read-write data store?
+
+It can technically be both, of course, which is why the question may be
+helpful: it may help show what is the *conceptual* purpose of the mbox
+output format for Bugs Everywhere.
+
+--
+ \ “Time is the great legalizer, even in the field of morals.” |
+ `\ —Henry L. Mencken |
+_o__) |
+Ben Finney
--- /dev/null
+Alt-id: <87hbxqrckv.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 06 Jul 2009 08:26:24 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae
+
--- /dev/null
+Gianluca Montecchi <gian@grys.it> writes:
+
+> 1) is it ok to develop this command ? I know that this is not a fully
+> featured web interface, but I am sure that it can be usefull.
+
+Yes, definitely. I can see it being a very easy way to put one's bug
+database online for browsing.
+
+> I am open to suggestion about it of course.
+
+Instead of a separate command for each output format, could we have a
+single “produce a static report of the bug database” command, and
+specify output format as an option?
+
+How about:
+
+ be report
+ be report --format ascii
+ be report --format rst
+ be report --format html
+
+Where the ‘--format’ option has a default of, e.g., “ascii”.
+
+This would mean that you are implementing the ‘html’ format of this
+putative command.
+
+> 2) I see that every command is implemented with a python file in the
+> becommand dir. For a better code, I'd like to split the command
+> implementation into two files: a file that contain the actual code and
+> a second file that have the html related part, any problem with this ?
+
+This sounds quite sensible to me. The existence of a command implies a
+module of the same name in ‘becommand’, but there's no necessary
+implication that that module can't import modules from elsewhere to do
+its work.
+
+--
+ \ “It ain't so much the things we don't know that get us in |
+ `\ trouble. It's the things we know that ain't so.” —Artemus Ward |
+_o__) (1834–1867), U.S. journalist |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <87y6r5qoyw.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 04 Jul 2009 10:19:35 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae
+
--- /dev/null
+Gianluca Montecchi <gian@grys.it> writes:
+
+> On Monday 06 July 2009 12:48:39 W. Trevor King wrote:
+> > Gianluca is clearly thinking about a static report [for a collection
+> > of HTML files as output]:
+>
+> You are right, static, but not exactly a report as I think Ben is
+> thinking
+
+I think it exactly is a report: multiple, static, browseable pages
+reporting the state of the database at a point in time.
+
+What makes you think that term doesn't apply?
+
+--
+ \ “The problem with television is that the people must sit and |
+ `\ keep their eyes glued on a screen: the average American family |
+_o__) hasn't time for it.” —_The New York Times_, 1939 |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <87skh9p8ax.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 07 Jul 2009 11:53:58 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae
+
--- /dev/null
+On Mon, Jul 06, 2009 at 08:26:24AM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+>
+> > On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote:
+> > > Instead of a separate command for each output format, could we have
+> > > a single "produce a static report of the bug database" command, and
+> > > specify output format as an option?
+> >
+> > Do people like this architecture better than my be-xml-to-mbox
+> > approach?
+>
+> I think this question is illuminated by the related question: Is mbox
+> output a static report, or another read-write data store?
+
+Gianluca is clearly thinking about a static report:
+
+On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
+> The goal is to be able to do something like "be html /web/page" to have in the
+> /web/page directory some static html pages that basically are the dump of the
+> be repository, much like ditz have
+
+I think truly interactive frontends like Steve's working on need to be
+build on top of libbe directly, since they'll need to make lots of
+small changes to the database, and it's to slow to be reloading the
+database for every change. Static dumps like my mbox or Gianluca's
+html could just parse the xml output of `be list' and other be
+commands.
+
+There should also be an xml import for `be new' and `be comment' so
+you could import new bugs/comments from whatever format after writing
+a whatever->xml converter. This would allow you to email new bugs and
+comments to the database (e.g. via some procmail-spawned
+be-parse-email script) which would give you some level of
+interactivity, but you'd have to regenerate your mbox to see your new
+comments in your mail reader.
+
+I think interactive use that gives you live-updates in your mail
+reader isn't worth the trouble, since you'd need to teach BE imap or
+smtp+mbox-locking. Hmm, maybe it smtp+mbox-locking wouldn't be so bad,
+but that would be a distinct frontend project like Steve's, not part
+of the becommands.
+
+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
--- /dev/null
+Alt-id: <20090706104839.GA19537@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 6 Jul 2009 06:48:39 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 074ef29a-3f1d-46dc-8561-7a56af7e6d67
+
--- /dev/null
+On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote:
+> Instead of a separate command for each output format, could we have a
+> single "produce a static report of the bug database" command, and
+> specify output format as an option?
+>
+> How about:
+>
+> be report
+> be report --format ascii
+> be report --format rst
+> be report --format html
+
+Do people like this architecture better than my be-xml-to-mbox
+approach? I think the tradeoff is easy output format implementation
+vs cluttered core codebase. Should we use both, depending on how
+useful people think the output format will be?
+
+--
+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
--- /dev/null
+Alt-id: <20090705143108.GB10709@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 5 Jul 2009 10:31:08 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 1dba8196-654b-4ca0-9a95-fb334af81863
+
--- /dev/null
+On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
+>
+> Hello to everyone
+>
+> As i said in a previous mail, I am working on a "html" command for be.
+> The goal is to be able to do something like "be html /web/page" to have in the
+> /web/page directory some static html pages that basically are the dump of the
+> be repository, much like ditz have
+> This will enable a simple and fast publish of the bus list and details on the
+> web, at least in read only mode.
+>
+> So I'd like to ask some question:
+> 1) is it ok to develop this command ? I know that this is not a fully featured
+> web interface, but I am sure that it can be usefull.
+>
+> I am open to suggestion about it of course.
+>
+> 2) I see that every command is implemented with a python file in the becommand
+> dir. For a better code, I'd like to split the command implementation into two
+> files: a file that contain the actual code and a second file that have the html
+> related part, any problem with this ? I don't like to have the html part and
+> the code part in one big and unreadable file.
+>
+> I'd like to hear other opinion about this.
+>
+> Thanks for now
+> bye
+> Gianluca
+>
+>
+> _______________________________________________
+> Be-devel mailing list
+> Be-devel@bugseverywhere.org
+> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
+
+On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote:
+> This sound like an interesting idea, but what i'd like to do is not, strictly
+> speaking, a report. It is a full tree of html pages that are browseable, both
+> on line and offline
+
+I'm not sure what distinction you're making about "report". You're
+just producing a static snapshot of the current database status,
+right? The number of pages and completeness of coverage are nice, but
+it's still a static entity generated from a particular snapshot, which
+is what I mean by "report" ;).
+
+> > > 2) I see that every command is implemented with a python file in the
+> > > becommand dir. For a better code, I'd like to split the command
+> > > implementation into two files: a file that contain the actual code and
+> > > a second file that have the html related part, any problem with this ?
+> >
+> > This sounds quite sensible to me. The existence of a command implies a
+> > module of the same name in ‘becommand’, but there's no necessary
+> > implication that that module can't import modules from elsewhere to do
+> > its work.
+>
+> The "elsewhere" for now is the same directory, just another module
+>
+
+On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote:
+> > On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
+> > > The goal is to be able to do something like "be html /web/page" to have
+> > > in the /web/page directory some static html pages that basically are the
+> > > dump of the be repository, much like ditz have
+> >
+> > I think truly interactive frontends like Steve's working on need to be
+> > build on top of libbe directly, since they'll need to make lots of
+> > small changes to the database, and it's to slow to be reloading the
+> > database for every change. Static dumps like my mbox or Gianluca's
+> > html could just parse the xml output of `be list' and other be
+> > commands.
+>
+> Ok, but if I want to have an html dump that is browseable, I need to parse the
+> xml. Am I correct ?
+> If yes, should not be easiear to use directly the libbe ?
+
+Using libbe directly is easier, but also more tightly tied to the be
+internals which could weigh down future refactoring. Partly I'm
+afraid of our 2.5 different html-output mechanisms. Either their
+should be a single Right Way that tries to satisfy everyone, or a
+smorgasbord of loosely coupled translators, so it's not so painful to
+kill them if/when they go out of style :p.
+
+On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote:
+> On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
+> > It might be a good idea for "be html" to use the CherryPy web interface
+> > that Steve is working on. The command could start up the CherryPy app
+> > and scrape all of the available pages to get a stand-alone dump; this
+> > would avoid having to keep two (okay, more than two at this point)
+> > separate sets of HTML templates in the source tree. What do you think?
+>
+> It can be do, but this implies that CherryPy must be installed and configured,
+> a thing that I don't want to impose. My idea is to offer a simpler way to have
+> some html pages, where you just need to have BE installed.
+
+I agree that not needing CherryPy for a static html dump is good.
+Also, read-only templates will look different from the CherryPy
+interactive templates. +1 for another quasi-redundant template set
+;).
+
+> > > 2) I see that every command is implemented with a python file in
+> > > the becommand dir. For a better code, I'd like to split the
+> > > command implementation into two files: a file that contain the
+> > > actual code and a second file that have the html related part,
+> > > any problem with this ? I don't like to have the html part and
+> > > the code part in one big and unreadable file.
+> >
+> > I agree that becommands/*.py commands should not contain any HTML
+> > layout code. Putting it somewhere else instead sounds fine.
+>
+> I am in doubt with the "somewhere else", since for now I put the html template
+> into a separate file in the same directory. Suggestion ?
+
+I think that only code intended only for command line use only should
+go into becommands, but really, just dump it anywhere and we can shift
+it around later :p.
+
+--
+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
--- /dev/null
+Alt-id: <20090707013454.GA3721@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 6 Jul 2009 21:34:54 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: da97e18f-33d6-469e-9d93-6457b9a6bfca
+
--- /dev/null
+On Saturday 04 July 2009 02:19:35 Ben Finney wrote:
+> Gianluca Montecchi <gian@grys.it> writes:
+
+>
+> > I am open to suggestion about it of course.
+>
+> Instead of a separate command for each output format, could we have a
+> single “produce a static report of the bug database” command, and
+> specify output format as an option?
+>
+> How about:
+>
+> be report
+> be report --format ascii
+> be report --format rst
+> be report --format html
+>
+> Where the ‘--format’ option has a default of, e.g., “ascii”.
+>
+> This would mean that you are implementing the ‘html’ format of this
+> putative command.
+>
+
+This sound like an interesting idea, but what i'd like to do is not, strictly
+speaking, a report. It is a full tree of html pages that are browseable, both
+on line and offline
+
+> > 2) I see that every command is implemented with a python file in the
+> > becommand dir. For a better code, I'd like to split the command
+> > implementation into two files: a file that contain the actual code and
+> > a second file that have the html related part, any problem with this ?
+>
+> This sounds quite sensible to me. The existence of a command implies a
+> module of the same name in ‘becommand’, but there's no necessary
+> implication that that module can't import modules from elsewhere to do
+> its work.
+
+The "elsewhere" for now is the same directory, just another module
+
+bye
+Gianluca
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907062218.33895.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 06 Jul 2009 22:18:33 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: 1dba8196-654b-4ca0-9a95-fb334af81863
+
--- /dev/null
+Hi Gianluca,
+
+ > As i said in a previous mail, I am working on a "html" command
+ > for be. The goal is to be able to do something like "be html
+ > /web/page" to have in the /web/page directory some static html
+ > pages that basically are the dump of the be repository, much like
+ > ditz have. This will enable a simple and fast publish of the bus
+ > list and details on the web, at least in read only mode.
+
+It might be a good idea for "be html" to use the CherryPy web interface
+that Steve is working on. The command could start up the CherryPy app
+and scrape all of the available pages to get a stand-alone dump; this
+would avoid having to keep two (okay, more than two at this point)
+separate sets of HTML templates in the source tree. What do you think?
+
+ > 2) I see that every command is implemented with a python file in
+ > the becommand dir. For a better code, I'd like to split the
+ > command implementation into two files: a file that contain the
+ > actual code and a second file that have the html related part,
+ > any problem with this ? I don't like to have the html part and
+ > the code part in one big and unreadable file.
+
+I agree that becommands/*.py commands should not contain any HTML
+layout code. Putting it somewhere else instead sounds fine.
+
+Thanks!
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <m3iqi9thk1.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Fri, 03 Jul 2009 20:31:26 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae
+
--- /dev/null
+> On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote:
+>> This sound like an interesting idea, but what i'd like to do is not,
+>> strictly
+>> speaking, a report. It is a full tree of html pages that are browseable,
+>> both
+>> on line and offline
+>
+> I'm not sure what distinction you're making about "report". You're
+> just producing a static snapshot of the current database status,
+> right? The number of pages and completeness of coverage are nice, but
+> it's still a static entity generated from a particular snapshot, which
+> is what I mean by "report" ;).
+
+Mmm, my bad here.
+I normally speak about "report" as something that is not browseable, like
+the output of a report generator (reportlab or whatever), but I admit that
+basically also the html output I am working on is a report.
+
+
+> On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote:
+>>
+>> Ok, but if I want to have an html dump that is browseable, I need to
+>> parse the
+>> xml. Am I correct ?
+>> If yes, should not be easiear to use directly the libbe ?
+>
+> Using libbe directly is easier, but also more tightly tied to the be
+> internals which could weigh down future refactoring. Partly I'm
+> afraid of our 2.5 different html-output mechanisms. Either their
+> should be a single Right Way that tries to satisfy everyone, or a
+> smorgasbord of loosely coupled translators, so it's not so painful to
+> kill them if/when they go out of style :p.
+
+I know that using libbe I am more tightly tied to the internals, but
+I am trying to keep the command code and the presentation code crearly
+separated to minimize this problem. I am not sure this is a real problem
+anyway.
+
+
+> On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote:
+>> On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
+>> > It might be a good idea for "be html" to use the CherryPy web
+>> interface
+>> > that Steve is working on. The command could start up the CherryPy app
+>> > and scrape all of the available pages to get a stand-alone dump; this
+>> > would avoid having to keep two (okay, more than two at this point)
+>> > separate sets of HTML templates in the source tree. What do you
+>> think?
+>>
+>> It can be do, but this implies that CherryPy must be installed and
+>> configured,
+>> a thing that I don't want to impose. My idea is to offer a simpler way
+>> to have
+>> some html pages, where you just need to have BE installed.
+>
+> I agree that not needing CherryPy for a static html dump is good.
+> Also, read-only templates will look different from the CherryPy
+> interactive templates. +1 for another quasi-redundant template set
+> ;).
+
+The look is not a problem. I can always use the same html Steve is using.
+I am also playing with the idea to have the template themeable some time
+after I have a fully working version.
+
+>
+>> > > 2) I see that every command is implemented with a python file in
+>> > > the becommand dir. For a better code, I'd like to split the
+>> > > command implementation into two files: a file that contain the
+>> > > actual code and a second file that have the html related part,
+>> > > any problem with this ? I don't like to have the html part and
+>> > > the code part in one big and unreadable file.
+>> >
+>> > I agree that becommands/*.py commands should not contain any HTML
+>> > layout code. Putting it somewhere else instead sounds fine.
+>>
+>> I am in doubt with the "somewhere else", since for now I put the html
+>> template
+>> into a separate file in the same directory. Suggestion ?
+>
+> I think that only code intended only for command line use only should
+> go into becommands, but really, just dump it anywhere and we can shift
+> it around later :p.
+
+Of course.
+
+bye
+Gianluca
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <6f719a1c43fdcba8bdbfee1130072595.squirrel@webmail.grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 07 Jul 2009 14:15:08 +0200
+
+
+From: gian@grys.it
+
+
+In-reply-to: 83202b83-eea8-452f-8239-d468940bddba
+
--- /dev/null
+Hello to everyone
+
+As i said in a previous mail, I am working on a "html" command for be.
+The goal is to be able to do something like "be html /web/page" to have in the
+/web/page directory some static html pages that basically are the dump of the
+be repository, much like ditz have
+This will enable a simple and fast publish of the bus list and details on the
+web, at least in read only mode.
+
+So I'd like to ask some question:
+1) is it ok to develop this command ? I know that this is not a fully featured
+web interface, but I am sure that it can be usefull.
+
+I am open to suggestion about it of course.
+
+2) I see that every command is implemented with a python file in the becommand
+dir. For a better code, I'd like to split the command implementation into two
+files: a file that contain the actual code and a second file that have the html
+related part, any problem with this ? I don't like to have the html part and
+the code part in one big and unreadable file.
+
+I'd like to hear other opinion about this.
+
+Thanks for now
+bye
+Gianluca
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907032250.17327.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Fri, 03 Jul 2009 22:50:17 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
--- /dev/null
+On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
+> Hi Gianluca,
+>
+> > As i said in a previous mail, I am working on a "html" command
+> > for be. The goal is to be able to do something like "be html
+> > /web/page" to have in the /web/page directory some static html
+> > pages that basically are the dump of the be repository, much like
+> > ditz have. This will enable a simple and fast publish of the bus
+> > list and details on the web, at least in read only mode.
+>
+> It might be a good idea for "be html" to use the CherryPy web interface
+> that Steve is working on. The command could start up the CherryPy app
+> and scrape all of the available pages to get a stand-alone dump; this
+> would avoid having to keep two (okay, more than two at this point)
+> separate sets of HTML templates in the source tree. What do you think?
+
+It can be do, but this implies that CherryPy must be installed and configured,
+a thing that I don't want to impose. My idea is to offer a simpler way to have
+some html pages, where you just need to have BE installed.
+
+My very first implementation was a script that parse directly the .be directory
+to build the pages, without BE itself installed.
+
+
+> > 2) I see that every command is implemented with a python file in
+> > the becommand dir. For a better code, I'd like to split the
+> > command implementation into two files: a file that contain the
+> > actual code and a second file that have the html related part,
+> > any problem with this ? I don't like to have the html part and
+> > the code part in one big and unreadable file.
+>
+> I agree that becommands/*.py commands should not contain any HTML
+> layout code. Putting it somewhere else instead sounds fine.
+
+I am in doubt with the "somewhere else", since for now I put the html template
+into a separate file in the same directory. Suggestion ?
+
+thanks
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907062246.54804.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 06 Jul 2009 22:46:54 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: b900f7fd-bab6-48c4-922c-a051f933da58
+
--- /dev/null
+On Thursday 25 June 2009 16:23:04 Steve Losh wrote:
+> On Jun 25, 2009, at 10:02 AM, Chris Ball <cjb@laptop.org> wrote:
+> >> Oh, and obviously there must still be bugs in BE. Please submit
+> >> more ;).
+> >
+> > Perhaps it's a good time to merge Steve Losh's CherryPy web interface?
+> >
+> > http://void.printf.net/pipermail/be-devel/2009-February/000095.html
+> > http://bitbucket.org/sjl/cherryflavoredbugseverywhere/
+>
+> Hey, I haven't touched the web interface in a while, but I should have
+> some time to fix some stuff up tonight and tomorrow. Hold off on
+> merging it in until then.
+>
+> I'm still curious as to what people think the role of a web interface
+> like this should be. When I wrote it I meant it as a single-user
+> interface like the command line one. It could definitely work as a
+> public, read-only interface too.
+
+I'd really like to have some sort of web interface for BE, also in read-only
+mode.
+
+I am thinking to write (actually I wrote some test code) a tool to parse a BE
+repository to output a set of static html pages to put online, like the "ditz
+html" command, but this was before I start to play with BE sourcecode, so now
+I ma thinking to implement it as a BE command.
+
+> If the goal is to allow more than one person to add issues, how should
+> commits go? One commit per change? Commit every X minutes if necessary?
+
+I think that a simple web interface should be read-only.
+
+Eventually, to allow to add issues also from the web interface, it should be
+done to a specific branch, one commit per change.
+
+just my 2 cents...
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200906252203.08535.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 25 Jun 2009 22:03:08 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
--- /dev/null
+On Monday 06 July 2009 12:48:39 W. Trevor King wrote:
+> On Mon, Jul 06, 2009 at 08:26:24AM +1000, Ben Finney wrote:
+> > "W. Trevor King" <wking@drexel.edu> writes:
+> > > On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote:
+> > > > Instead of a separate command for each output format, could we have
+> > > > a single "produce a static report of the bug database" command, and
+> > > > specify output format as an option?
+> > >
+> > > Do people like this architecture better than my be-xml-to-mbox
+> > > approach?
+> >
+> > I think this question is illuminated by the related question: Is mbox
+> > output a static report, or another read-write data store?
+>
+> Gianluca is clearly thinking about a static report:
+
+You are right, static, but not exactly a report as I think Ben is thinking
+
+>
+> On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
+> > The goal is to be able to do something like "be html /web/page" to have
+> > in the /web/page directory some static html pages that basically are the
+> > dump of the be repository, much like ditz have
+>
+> I think truly interactive frontends like Steve's working on need to be
+> build on top of libbe directly, since they'll need to make lots of
+> small changes to the database, and it's to slow to be reloading the
+> database for every change. Static dumps like my mbox or Gianluca's
+> html could just parse the xml output of `be list' and other be
+> commands.
+
+Ok, but if I want to have an html dump that is browseable, I need to parse the
+xml. Am I correct ?
+If yes, should not be easiear to use directly the libbe ?
+
+
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907062238.56930.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Mon, 06 Jul 2009 22:38:56 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: 55263144-9775-4b18-ab83-29d66ed91a53
+
--- /dev/null
+assigned: Gianluca Montecchi <gian@grys.it>
+
+
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: Gianluca Montecchi <gian@grys.it>
+
+
+severity: wishlist
+
+
+status: assigned
+
+
+summary: Static html report generation
+
+
+time: Tue, 21 Jul 2009 18:43:06 +0000
+
--- /dev/null
+* W. Trevor King (wking@drexel.edu) wrote:
+> One problem is that we don't actually have "releases". People just
+> clone a branch, install, and go.
+
+ This is actually the main reason I've manually mirrored the tree in
+the past, so that users of our projects can get BE. If tarballs were
+available I probably wouldn't even bother, but bzr really isn't a nice
+dependency for just submitting/commenting on bugs.
+
+ Isn't there a bzr web interface that at least supports creating
+tarballs/zips? It is pretty standard functionality for most other VCS'
+web interfaces so I'm guessing there must be, but loggerhead seems not
+to support it.
+
+ If it is a case of not having the hardware to host a more featureful
+web UI I may be able to offer some assistance.
+
+> If you're worried about stability, just clone from a more stable branch
+> (i.e., Chris' trunk). I think > this is good for distributed development,
+> but maybe makes it hard to package into a conventional release-based system.
+> With the bzr patch number in setup.py as the patch release number, I would be
+> releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at
+> about the same point. I would rather be releasing my
+> 0.1.20090714121347
+> while Chris releases his
+> 0.1.20090713154540
+> Since then the similarity is clearer.
+
+ Both approaches seem pretty odd to me, as a user you would have no
+idea if 0.1.200910302359 has the fixes you required in a release you
+were using that was numbered 0.1.200907141554. Surely you'd at least be
+{pre,suf}fixing a branch name to the version.
+
+Thanks,
+
+James
--- /dev/null
+Alt-id: <20090714142942.GA5717@ukfsn.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 15:29:42 +0100
+
+
+From: James Rowe <jnrowe@gmail.com>
+
+
+In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b
+
--- /dev/null
+On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
+> * W. Trevor King (wking@drexel.edu) wrote:
+> > One problem is that we don't actually have "releases". People just
+> > clone a branch, install, and go.
+>
+> This is actually the main reason I've manually mirrored the tree in
+> the past, so that users of our projects can get BE. If tarballs were
+> available I probably wouldn't even bother, but bzr really isn't a nice
+> dependency for just submitting/commenting on bugs.
+
+Fair enough. It will be good when we get a commit-able web interface
+and/or email interface going.
+
+> Isn't there a bzr web interface that at least supports creating
+> tarballs/zips? It is pretty standard functionality for most other VCS'
+> web interfaces so I'm guessing there must be, but loggerhead seems not
+> to support it.
+
+Unfortunately, people would still need bzr to install the versioned source:
+
+ libbe/_version.py:
+ bzr version-info --format python > $@
+
+So you'll need a "release" target in the makefile to build a bzr-less
+install. While you're at it, you should probably compile the manpage
+too to remove the docbook-to-man dependency.
+
+Do people want a HEAD tarball too? There must be a bzr equivalent of
+ .git/hooks/post-update
+but I don't know what it is.
+
+> > If you're worried about stability, just clone from a more stable branch
+> > (i.e., Chris' trunk). I think > this is good for distributed development,
+> > but maybe makes it hard to package into a conventional release-based system.
+> > With the bzr patch number in setup.py as the patch release number, I would be
+> > releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at
+> > about the same point. I would rather be releasing my
+> > 0.1.20090714121347
+> > while Chris releases his
+> > 0.1.20090713154540
+> > Since then the similarity is clearer.
+>
+> Both approaches seem pretty odd to me, as a user you would have no
+> idea if 0.1.200910302359 has the fixes you required in a release you
+> were using that was numbered 0.1.200907141554. Surely you'd at least be
+> {pre,suf}fixing a branch name to the version.
+
+"be --version" currently gives you the revision id:
+ wking@drexel.edu-20090714121347-c6rloikst1t3m5yl
+which tells you exactly which commit your installed version is based on.
+If we want stick with revision numbers, how about:
+ major.minor.revno-branch_nick
+But then we'd have to pick "unique" branch nicknames...
+
+I'd sliced out the timestamp portion of the revision id so that the
+"patch-number" would be an integer and the branch name wasn't
+references, so that "upgrading" from one branch to another could be
+transparent to the users (who just see an increading timestamp), but
+still available to the developers (who know when commits were made to
+the branches they track, and the likelyhood of to-the-second commit
+collisions in official packages is small).
+
+On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+>
+> > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > Please, no. Timestamps aren't version strings, that's conflating two
+> > > pieces of information with very different meanings. Correlating the
+> > > two is the job of a changelog.
+> >
+> > Which we don't bother keeping (also NEWS), since "bzr log" works so
+> > nicely.
+>
+> That's not a changelog, that's a commit log of every source-level commit
+> made. Far too much detail for a changelog of *user-visible* changes
+> associated with a release.
+
+I need a user around to help me determine "user-visable" changes ;).
+My labmates loose interest after be init/new/comment :p. None of
+which has ever changed, other than set-root -> init ;).
+
+> > The timestamp should at least replace the patch release number, which
+> > you agree is-desirable-to increase motonically ;).
+>
+> I still disagree that a timestamp is the right thing to use there. If
+> you want a monotonically-increasing indicator of which revision we're up
+> to, that's immediately available with the revision number from VCS on
+> the main branch. That also has the advantage of producing consecutive
+> numbers for each revision, by definition.
+
+But not during branch-switches, while my method skips large regions,
+but probably increases during any reasonable branch-switch. For
+example, when I upgraded to rich root to pull Ben's patch, I'm not
+sure if Chris upgraded the trunk and merged my branch, or just ditched
+the trunk and cloned my branch. Using actual bzr revision numbers
+would make switching branches that either wrong (in the case of
+rev-id decreases) or confusing (in the case of a single
+non-consecutive increase).
+
+On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote:
+> > I agree that's a problem. I think the solution is to start making
+> > releases, with specific version strings, as source tarballs.
+>
+> I'm happy to do this if people think it would be useful, and I don't
+> yet have a strong opinion on whether the releases should come with
+> version numbers or timestamps.
+
+I imagine the news from 2006 to now will be somewhat abridged ;).
+
+--
+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
--- /dev/null
+Alt-id: <20090714171725.GB10445@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 13:17:25 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 0c40c13a-3515-4b45-a8c3-142cceab9254
+
--- /dev/null
+Chris Ball <cjb@laptop.org> writes:
+
+> Hi,
+>
+> > That's not a changelog, that's a commit log of every source-level
+> > commit made. Far too much detail for a changelog of
+> > *user-visible* changes associated with a release.
+>
+> I think I agree with both of you. :) It seems like it's both true that
+> there's no point in keeping a GNU-style ChangeLog these days
+
+I think I have a better understanding of why this apparent disagreement
+occurred, and it was due to my sloppy use of terms.
+
+Looking into it further, it seems there is a certain expectation (set,
+in part, by the long-standing GNU coding conventions) that a “GNU-style
+ChangeLog” contains not only a particular *format*, but information at
+a particular level of *detail*.
+
+That is, a GNU ChangeLog is intended for the style of work where one
+logs all the changes made to every file in the tree each working day,
+and then makes a new day's entry above that, and so on. This is, of
+course, entirely redundant with a VCS revision history, which makes all
+the commit messages available on request.
+
+So to disambiguate, that's not what I meant. I'm more familiar with a
+less-frequently-updated and less-fine-detail change log; perhaps more
+akin to the GNU-style “NEWS” file.
+
+> and that if we make a release we should write an announce mail that
+> directly mentions new user-visible changes as well as attaching the
+> commit log. That smaller list of highly user-visible changes could
+> live in NEWS, or in the announce mail, or both.
+
+Yes, that's mostly what I meant.
+
+I actually don't think the commit log needs to be part of the release at
+all. It's of interest only to those who want fine-level detail about
+changes to every file, and for that purpose I think read access to the
+VCS is much better. Packaging a static copy of the commit log as plain
+text seems pointless.
+
+Rather, we should treat a user-changes level “NEWS” file (or whatever
+name we choose for it) as part of the documentation, and set the
+expectation among the team that it will be updated for each user-visible
+change being worked on, like any other documentation.
+
+--
+ \ “… Nature … is seen to do all things Herself and through |
+ `\ herself of own accord, rid of all gods.” —Titus Lucretius |
+_o__) Carus, c. 40 BCE |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <87hbxdhtkp.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 16 Jul 2009 19:21:10 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
--- /dev/null
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+W. Trevor King wrote:
+> Thinking about this some more, I think that the role of the
+> main-branch is to officially sanction the current state of the code as
+> "released". If a series of commits will leave a branch in a
+> known-unusable form, they should be carried out in some appropriately
+> named development branch. Then the log of commits to the main branch
+> ("bzr log -n 1" for bzr > ) should produce a fairly respectable
+> changelog.
+
+This is how we develop bzr itself. The mainline is controlled by PQM,
+which is a tool that merges feature branches, runs the tests, and
+commits only if the tests pass.
+
+$ bzr log --short --limit 10
+ 4534 Canonical.com Patch Queue Manager 2009-07-14 [merge]
+ (abentley) Implement merge --interactive
+
+ 4533 Canonical.com Patch Queue Manager 2009-07-14 [merge]
+ (jml) Merge in changes from 1.17 branch.
+
+ 4532 Canonical.com Patch Queue Manager 2009-07-14 [merge]
+ (igc) zc.buildout Windows build support (Sidnei da Silva)
+
+ 4531 Canonical.com Patch Queue Manager 2009-07-13 [merge]
+ (vila) Delete forgotten debug print
+
+ 4530 Canonical.com Patch Queue Manager 2009-07-13 [merge]
+ (vila) Isolate some tests from TZ
+
+ 4529 Canonical.com Patch Queue Manager 2009-07-13 [merge]
+ (igc) Bazaar 2.0 Upgrade Guide
+
+ 4528 Canonical.com Patch Queue Manager 2009-07-13 [merge]
+ (mbp) correction to news
+
+ 4527 Canonical.com Patch Queue Manager 2009-07-13 [merge]
+ (jml) Merge in 1.17 branch, updating version numbers and NEWS file.
+
+ 4526 Canonical.com Patch Queue Manager 2009-07-10 [merge]
+ (mbp, vila) Finish the *_implementation to per_* test renaming
+
+ 4525 Canonical.com Patch Queue Manager 2009-07-10 [merge]
+ (vila) Quicker check for changes in mutable trees
+
+You can also see all the merges as they come into the mainline:
+
+$ bzr log --short --limit 10 --include-merges
+ 4534 Canonical.com Patch Queue Manager 2009-07-14 [merge]
+ (abentley) Implement merge --interactive
+
+ 4526.6.15 Aaron Bentley 2009-07-14
+ Update command help
+
+ 4526.6.14 Aaron Bentley 2009-07-14
+ Use default DiffWriter.
+
+ 4526.6.13 Aaron Bentley 2009-07-14
+ Add docstring to do_interactive.
+
+ 4526.6.12 Aaron Bentley 2009-07-14
+ Updates from review.
+
+ 4526.6.11 Aaron Bentley 2009-07-13
+ Update NEWS.
+
+ 4526.6.10 Aaron Bentley 2009-07-13 [merge]
+ Merged apply-vocab into merge-interactive.
+
+ 4526.7.4 Aaron Bentley 2009-07-13 [merge]
+ Merged bzr.dev into apply-vocab.
+
+ 4526.6.9 Aaron Bentley 2009-07-13 [merge]
+ Merged apply-vocab into merge-interactive.
+
+ 4526.7.3 Aaron Bentley 2009-07-13
+ Test shelve_change.
+
+> This also means that _every_commit_ to a main branch would
+> be an official release.
+
+We don't do that. We have official releases every 4 weeks, but we do
+believe that running bzr.dev is pretty safe, because it's always tested
+and our test suite is quite thorough.
+
+Aaron
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.9 (GNU/Linux)
+Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
+
+iEYEARECAAYFAkpcznIACgkQ0F+nu1YWqI0yhACePTFUUp6u+Dw+8IRwWOWBQRtb
+TgsAniJq4lqnDfjNACMr7IEt7xYJhx7m
+=BbGG
+-----END PGP SIGNATURE-----
--- /dev/null
+Alt-id: <4A5CCE76.9040106@aaronbentley.com>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 14:29:10 -0400
+
+
+From: Aaron Bentley <aaron@aaronbentley.com>
+
+
+In-reply-to: ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68
+
--- /dev/null
+On Tue, Jul 14, 2009 at 07:34:04PM +0100, jnrowe@gmail.com wrote:
+> [This time to the list]
+>
+> * W. Trevor King (wking@drexel.edu) wrote:
+> > On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
+> > > Isn't there a bzr web interface that at least supports creating
+> > > tarballs/zips? It is pretty standard functionality for most other VCS'
+> > > web interfaces so I'm guessing there must be, but loggerhead seems not
+> > > to support it.
+> >
+> > Unfortunately, people would still need bzr to install the versioned source:
+> >
+> > libbe/_version.py:
+> > bzr version-info --format python > $@
+>
+> I hadn't even seen that change go in. The last upstream change in the
+> version I have installed locally was by you on 2008-11-24.
+
+It's only been in Chris' http://bzr.bugseverywhere.org/be/ branch
+since revno: 321, 2009-06-25. Obviously we may have to adjust the
+--verison output once we settle on a versioning scheme, but whatever
+we pick, I think having the auto-generated libbe/_version.py around
+for pinpointing bugs is worth the trouble of requiring bzr when
+building distribution tarballs.
+
+> > So you'll need a "release" target in the makefile to build a bzr-less
+> > install. While you're at it, you should probably compile the manpage
+> > too to remove the docbook-to-man dependency.
+>
+> Maybe for others. Our packages just don't have the manpage as it is only
+> the "be help" text reformatted, the easy option is sometimes the right
+> one :) Also, I've just noticed that it has even less documentation in
+> the bzr tree[1] making its installation much less compelling unless your
+> packaging rules require a man page like Debians.
+>
+> Out of curiosity why is the Makefile being used for this stuff anyway?
+> It is going to make it difficult to build locally when we finally get
+> around to merging. Examples: If distutils was being used exclusively it
+> would fix the #! lines in xml/*. We'd be able to point Python
+> $version_of_the_day at setup.py instead of having to sed the Makefile or
+> run setup and manually install other files.
+
+I speak Makefile better than I speak distutils ;). I'm not sure how
+to translate the be.1 generation/installation or the libbe/_version.py
+generation into distutils. Anyone else?
+
+--
+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
--- /dev/null
+Alt-id: <20090714191145.GB10606@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 15:11:45 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 6e315abe-a080-4369-8729-4aea2dee8494
+
--- /dev/null
+[This time to the list]
+
+* W. Trevor King (wking@drexel.edu) wrote:
+> On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
+> > Isn't there a bzr web interface that at least supports creating
+> > tarballs/zips? It is pretty standard functionality for most other VCS'
+> > web interfaces so I'm guessing there must be, but loggerhead seems not
+> > to support it.
+>
+> Unfortunately, people would still need bzr to install the versioned source:
+>
+> libbe/_version.py:
+> bzr version-info --format python > $@
+
+ I hadn't even seen that change go in. The last upstream change in the
+version I have installed locally was by you on 2008-11-24.
+
+> So you'll need a "release" target in the makefile to build a bzr-less
+> install. While you're at it, you should probably compile the manpage
+> too to remove the docbook-to-man dependency.
+
+ Maybe for others. Our packages just don't have the manpage as it is only
+the "be help" text reformatted, the easy option is sometimes the right
+one :) Also, I've just noticed that it has even less documentation in
+the bzr tree[1] making its installation much less compelling unless your
+packaging rules require a man page like Debians.
+
+ Out of curiosity why is the Makefile being used for this stuff anyway?
+It is going to make it difficult to build locally when we finally get
+around to merging. Examples: If distutils was being used exclusively it
+would fix the #! lines in xml/*. We'd be able to point Python
+$version_of_the_day at setup.py instead of having to sed the Makefile or
+run setup and manually install other files.
+
+Thanks,
+
+James
+ 1. http://pullcord.laptop.org:4000/revision/314.1.15/doc/be.1.sgml
--- /dev/null
+Alt-id: <20090714183404.GB26032@ukfsn.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 19:34:04 +0100
+
+
+From: jnrowe@gmail.com
+
+
+In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624
+
--- /dev/null
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> Currently setup.py sets the version number for BE to 0.0.193 and the
+> url to http://panoramicfeedback.com/opensource/. These are both a bit
+> outdated ;).
+
+Right, that should change.
+
+> I've switched my branch over to the current url, and moved to
+> last-commit-timestamp version numbers.
+
+Please, no. Timestamps aren't version strings, that's conflating two
+pieces of information with very different meanings. Correlating the two
+is the job of a changelog.
+
+> This removes the "prefered branch" issues with the old scheme, and
+> version numbers should increase monotonically
+
+The English word “should” is ambiguous in this context. Are you saying
+this is desirable, or are you predicting that it will likely be the
+case?
+
+I don't see how it's either, so am doubly confused :-)
+
+> but it looses any stability information suggested by the preceding
+> 0.0.
+
+The convention for three-part version strings is often:
+
+ * Major release number (big changes in how the program works,
+ increasing monotonically per major release, with “0”indicating no
+ major release yet)
+
+ * Minor release number (smaller impact on how the program works,
+ increasing monotonically per minor release, with “0” indicating no
+ minor release yet since the previous major)
+
+ * Patch release number (bug-fix and other changes that don't affect
+ the documented interface, increasing monotonically per patch
+ release, with “0” indicating no patch release since the previous
+ major or minor)
+
+Obviously there's no standard or enforcement for this, but that's the
+interpretation I usually give to dotted version strings in the absence
+of more formal declaration specific to the project.
+
+> We can add those back in if people want. Does the first 0 mean
+> "interfaces in flux" and the second 0 mean "lots of bugs"? If so, I
+> think we're up to 0.1, since the major features are pretty calm.
+
+I disagree with your interpretation and prefer mine, above; on that
+basis, I agree that we're at least up to version 0.1 by now :-)
+
+--
+ \ “A lot of water has been passed under the bridge since this |
+ `\ variation has been played.” chess book, Russia |
+_o__) |
+Ben Finney
--- /dev/null
+Alt-id: <87ocrnjvat.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 22:36:26 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
--- /dev/null
+Hi,
+
+ > Which we don't bother keeping (also NEWS), since "bzr log" works
+ > so nicely. If you really want an standard changelog, see
+ > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html
+
+Actually, there's a `bzr log --gnu-changelog` now, and `bzr help
+log-formats` offers some more styles. (None of them seem to match
+my preferred style for release announcements exactly, which would
+be `git shortlog`-style.)
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
--- /dev/null
+Alt-id: <m3ljmrfgot.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 11:05:38 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b
+
--- /dev/null
+I don't think anyone's changing their mind ;), so tallying the
+comments so far:
+
+On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> I still disagree that a timestamp is the right thing to use there. If
+> you want a monotonically-increasing indicator of which revision we're up
+> to, that's immediately available with the revision number from VCS on
+> the main branch. That also has the advantage of producing consecutive
+> numbers for each revision, by definition.
+
++1 for trunk version number.
+
+On Tue, Jul 14, 2009 at 05:27:52PM +0200, Elena of Valhalla wrote:
+> I also have a weak preference for version numbers, as long as they
+> give useful informations on the state the release.
+
++1 for trunk version number.
+
+On Tue, Jul 14, 2009 at 02:29:10PM -0400, Aaron Bentley wrote:
+> We don't do that. We have official releases every 4 weeks, but we do
+> believe that running bzr.dev is pretty safe, because it's always tested
+> and our test suite is quite thorough.
+
++1 for by hand version bumps.
+
+On Fri, Jul 17, 2009 at 11:37:49PM +0200, Gianluca Montecchi wrote:
+> The version number of trunk _is_ should be the official version number of the
+> Bugs Everywhere releases.
+> The version number in branch does not means nothing outside the branch.
+> At least we can have a mechanism to build a version number scheme that is
+> consistent for us to be able to merge branch easily.
+
++1 for trunk version number.
+
+And me with my timestamps ;).
+
+Sounds like we should go with trunk version number, but that it should
+be set by hand whenever Chris decides to release something, since the
+rest of us don't know what version the trunk is on. Unless we do
+something like:
+ bzr log -n 0 | grep -B2 'nick: be$' | head -n1 | sed 's/ *revno: \([0-9]*\).*/\1/'
+to extract the last trunk commit referenced from our branch.
+
+Implementation preferences? (i.e. Chris vs. regexp matching :p)
+
+--
+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
--- /dev/null
+Alt-id: <20090718105008.GA31639@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 06:50:08 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: c35835c0-8f9f-4090-ba92-1f616867e486
+
--- /dev/null
+Hi,
+
+ > That's not a changelog, that's a commit log of every source-level
+ > commit made. Far too much detail for a changelog of
+ > *user-visible* changes associated with a release.
+
+I think I agree with both of you. :) It seems like it's both true that
+there's no point in keeping a GNU-style ChangeLog these days, and that
+if we make a release we should write an announce mail that directly
+mentions new user-visible changes as well as attaching the commit log.
+That smaller list of highly user-visible changes could live in NEWS,
+or in the announce mail, or both.
+
+ > I agree that's a problem. I think the solution is to start making
+ > releases, with specific version strings, as source tarballs.
+
+I'm happy to do this if people think it would be useful, and I don't
+yet have a strong opinion on whether the releases should come with
+version numbers or timestamps.
+
+Thanks,
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <m3k52bfgf0.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 11:11:31 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42
+
--- /dev/null
+On Tue, Jul 14, 2009 at 01:17:25PM -0400, W. Trevor King wrote:
+> On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > "W. Trevor King" <wking@drexel.edu> writes:
+> >
+> > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > Please, no. Timestamps aren't version strings, that's conflating two
+> > > > pieces of information with very different meanings. Correlating the
+> > > > two is the job of a changelog.
+> > >
+> > > Which we don't bother keeping (also NEWS), since "bzr log" works so
+> > > nicely.
+> >
+> > That's not a changelog, that's a commit log of every source-level commit
+> > made. Far too much detail for a changelog of *user-visible* changes
+> > associated with a release.
+>
+> I need a user around to help me determine "user-visable" changes ;).
+> My labmates loose interest after be init/new/comment :p. None of
+> which has ever changed, other than set-root -> init ;).
+
+Thinking about this some more, I think that the role of the
+main-branch is to officially sanction the current state of the code as
+"released". If a series of commits will leave a branch in a
+known-unusable form, they should be carried out in some appropriately
+named development branch. Then the log of commits to the main branch
+("bzr log -n 1" for bzr > ) should produce a fairly respectable
+changelog. Obviously we are all quite guilty of doing most of our
+development in single branches, but it may be a useful model going
+forward. This also means that _every_commit_ to a main branch would
+be an official release.
+
+--
+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
--- /dev/null
+Alt-id: <20090714182034.GA10606@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 14:20:34 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624
+
--- /dev/null
+On Tue, Jul 14, 2009 at 5:11 PM, Chris Ball<cjb@laptop.org> wrote:
+> > I agree that's a problem. I think the solution is to start making
+> > releases, with specific version strings, as source tarballs.
+>
+> I'm happy to do this if people think it would be useful, and I don't
+> yet have a strong opinion on whether the releases should come with
+> version numbers or timestamps.
+
+as an user of be that plans to try and "package" it for openembedded,
+a release would be very useful: writing a recipe that downloads a
+specific commit from bzr and builds it is probably feasible, but
+definitely not ideal.
+
+I also have a weak preference for version numbers, as long as they
+give useful informations on the state the release.
+
+--
+Elena ``of Valhalla''
+
+email: elena.valhalla@gmail.com
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <5c5e5c350907140827u218553e8rc5773325d43c2bf2@mail.gmail.com>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 17:27:52 +0200
+
+
+From: Elena of Valhalla <elena.valhalla@gmail.com>
+
+
+In-reply-to: aad59898-8949-44fb-ad0b-2acea6eb2ef8
+
--- /dev/null
+On Thursday 16 July 2009 12:38:55 W. Trevor King wrote:
+> On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote:
+> > "W. Trevor King" <wking@drexel.edu> writes:
+> > > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > > > "W. Trevor King" <wking@drexel.edu> writes:
+> > > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > > > Please, no. Timestamps aren't version strings, that's conflating
+> > > > > > two pieces of information with very different meanings.
+> > > > > > Correlating the two is the job of a [NEWS file].
+> > > >
+> > > > If you want a monotonically-increasing indicator of which revision
+> > > > we're up to, that's immediately available with the revision number
+> > > > from VCS on the main branch. That also has the advantage of
+> > > > producing consecutive numbers for each revision, by definition.
+> > >
+> > > But not during branch-switches, while my method skips large regions,
+> > > but probably increases during any reasonable branch-switch.
+> >
+> > I've read this several times now, and I don't see what it's saying.
+> >
+> > The assumption I'm making is that there is a single canonical “main
+> > branch”, from which releases will be made.
+>
+> I don't think you need to assume this. See my "virtual branch"
+> argument below.
+
+But if we have a canonical "main branch" that we release, and the packager
+get, we can refer to it as the stable branch, that it is not a bad idea.
+
+
+
+> > The version number set in that branch is the one which determines
+> > the version of Bugs Everywhere as a whole.
+>
+> If you are suggesting that the dev branches adjust their release
+> number _by_hand_ to match the current trunk release number, that
+> allows switching, but sounds like a lot of work and isn't correct
+> anyway, since they are not in the same state as the trunk.
+
+The version number of trunk _is_ should be the official version number of the
+Bugs Everywhere releases.
+The version number in branch does not means nothing outside the branch.
+At least we can have a mechanism to build a version number scheme that is
+consistent for us to be able to merge branch easily.
+
+> > The revision number is only useful in the context of the branch, so it
+> > only matters when comparing versions within a branch. When you switch
+> > between branches, if you're interested in the revision number you'll
+> > still need to know which branch you're talking about.
+>
+> I think this is our main disagreement. I see all the branches as part
+> of the same codebase, with monotonically increasing timestamp patch
+> numbers. If you were to collapse all the commit snapshots down into a
+> single chronological "virtual branch", it would still make sense, it
+> would just be a bit unorganized. We do all try to move in the same
+> general direction ;).
+
+I don't think that, outside the developers, a version number like
+
+cjb@laptop.org-20090713154540-ve4pmydqzb1ghgvc
+
+is a good choice, not for the user of BE, not for the packager of BE
+
+
+> > This, then, is an argument for not having the revision number in the
+> > version string at all. The version then becomes a more traditional
+> > “major.minor.patch” tuple, and is only ever updated when some release
+> > manager of the canonical branch decides it's correct to do so.
+>
+> It is an argument for not using the revision number. You can avoid
+> revision numbers by using hand-coded patch numbers, or by using
+> timestamps, which is what we're trying to decide on :p.
+
+We can use both.
+During the development we can use version number like
+
+x.y.z.timestamp
+
+As we decide to release a stable version, the release manager set the version
+number to a more traditional x.y.z format, and create a branch (stable branch)
+
+This way we have these advantages:
+
+1) an user have a simple version number to use for bug report/feature
+request/help request
+
+2) a packager have an easy life to choose to package a stable or a trunk
+version, knowing what are they doing
+
+bonus) we can maintain a stable and a developmente source tree/branch, where
+in the development tree we can make also backward incompatible modification to
+the source without making any damage to the users/packagers, while in the
+stable branch we can make only bugfix/security fix or port from the devel branch
+some interesting features as long as they don't break compatibility.
+
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <200907172337.49779.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Fri, 17 Jul 2009 23:37:49 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: f925e56f-26f9-4620-82fb-a0f160f27921
+
--- /dev/null
+Currently setup.py sets the version number for BE to 0.0.193 and the
+url to http://panoramicfeedback.com/opensource/. These are both a bit
+outdated ;). I've switched my branch over to the current url, and
+moved to last-commit-timestamp version numbers. This removes the
+"prefered branch" issues with the old scheme, and version numbers
+should increase monotonically, but it looses any stability information
+suggested by the preceding 0.0.
+
+We can add those back in if people want. Does the first 0 mean
+"interfaces in flux" and the second 0 mean "lots of bugs"? If so, I
+think we're up to 0.1, since the major features are pretty calm.
+
+--
+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
--- /dev/null
+Alt-id: <20090714110543.GB4855@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 07:05:43 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
--- /dev/null
+On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+> > I've switched my branch over to the current url, and moved to
+> > last-commit-timestamp version numbers.
+>
+> Please, no. Timestamps aren't version strings, that's conflating two
+> pieces of information with very different meanings. Correlating the two
+> is the job of a changelog.
+
+Which we don't bother keeping (also NEWS), since "bzr log" works so nicely.
+If you really want an standard changelog, see
+ http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html
+
+> > This removes the "prefered branch" issues with the old scheme, and
+> > version numbers should increase monotonically
+>
+> The English word “should” is ambiguous in this context. Are you saying
+> this is desirable, or are you predicting that it will likely be the
+> case?
+
+Both.
+
+> I don't see how it's either, so am doubly confused :-)
+
+The timestamp should at least replace the patch release number, which
+you agree is-desirable-to increase motonically ;). I also predict
+that it will increase monotonically for any given branch, since the
+branch HEAD will have both the most recent commit and the highest
+version number. The only problem I can think of is having your clock
+_way_ off, and that is unlikely enough to ignore. If you hop between
+branches, the timestamp is much more likely to increase going to the
+more modern branch than the bzr revision number, which desynchronize
+between branches fairly quickly.
+
+> The convention for three-part version strings is often:
+>
+> * Major release number (big changes in how the program works,
+> increasing monotonically per major release, with “0”indicating no
+> major release yet)
+>
+> * Minor release number (smaller impact on how the program works,
+> increasing monotonically per minor release, with “0” indicating no
+> minor release yet since the previous major)
+>
+> * Patch release number (bug-fix and other changes that don't affect
+> the documented interface, increasing monotonically per patch
+> release, with “0” indicating no patch release since the previous
+> major or minor)
+
+One problem is that we don't actually have "releases". People just
+clone a branch, install, and go. If you're worried about stability,
+just clone from a more stable branch (i.e., Chris' trunk). I think
+this is good for distributed development, but maybe makes it hard to
+package into a conventional release-based system. With the bzr patch
+number in setup.py as the patch release number, I would be releasing
+my 0.1.363 while Chris releases his 0.1.314, even though they're at
+about the same point. I would rather be releasing my
+ 0.1.20090714121347
+while Chris releases his
+ 0.1.20090713154540
+Since then the similarity is clearer.
+
+At any rate, I think the two approaches are close enough that an
+auto-updating timestamp beats a manually bumped patch number, since
+no-one ever actually bumps the patch number ;).
+
+--
+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
--- /dev/null
+Alt-id: <20090714133732.GB6160@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 09:37:32 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 744435b7-1521-4059-a55d-f0c403d7b4d8
+
--- /dev/null
+On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+>
+> > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > > "W. Trevor King" <wking@drexel.edu> writes:
+> > >
+> > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > > Please, no. Timestamps aren't version strings, that's conflating
+> > > > > two pieces of information with very different meanings.
+> > > > > Correlating the two is the job of a [NEWS file].
+> >
+> > > If you want a monotonically-increasing indicator of which revision
+> > > we're up to, that's immediately available with the revision number
+> > > from VCS on the main branch. That also has the advantage of
+> > > producing consecutive numbers for each revision, by definition.
+> >
+> > But not during branch-switches, while my method skips large regions,
+> > but probably increases during any reasonable branch-switch.
+>
+> I've read this several times now, and I don't see what it's saying.
+>
+> The assumption I'm making is that there is a single canonical “main
+> branch”, from which releases will be made.
+
+I don't think you need to assume this. See my "virtual branch"
+argument below.
+
+> The version number set in that branch is the one which determines
+> the version of Bugs Everywhere as a whole.
+
+If you are suggesting that the dev branches adjust their release
+number _by_hand_ to match the current trunk release number, that
+allows switching, but sounds like a lot of work and isn't correct
+anyway, since they are not in the same state as the trunk.
+
+> The revision number is only useful in the context of the branch, so it
+> only matters when comparing versions within a branch. When you switch
+> between branches, if you're interested in the revision number you'll
+> still need to know which branch you're talking about.
+
+I think this is our main disagreement. I see all the branches as part
+of the same codebase, with monotonically increasing timestamp patch
+numbers. If you were to collapse all the commit snapshots down into a
+single chronological "virtual branch", it would still make sense, it
+would just be a bit unorganized. We do all try to move in the same
+general direction ;).
+
+> Switching between branches doesn't change the canonical version string.
+
+Different released code should have different version numbers.
+
+> > For example, when I upgraded to rich root to pull Ben's patch, I'm not
+> > sure if Chris upgraded the trunk and merged my branch, or just ditched
+> > the trunk and cloned my branch. Using actual bzr revision numbers
+> > would make switching branches that either wrong (in the case of rev-id
+> > decreases) or confusing (in the case of a single non-consecutive
+> > increase).
+>
+> This, then, is an argument for not having the revision number in the
+> version string at all. The version then becomes a more traditional
+> “major.minor.patch” tuple, and is only ever updated when some release
+> manager of the canonical branch decides it's correct to do so.
+
+It is an argument for not using the revision number. You can avoid
+revision numbers by using hand-coded patch numbers, or by using
+timestamps, which is what we're trying to decide on :p.
+
+> If we use the ‘bzr version-info --format=python > foo_version.py’
+> command in some build routine, the branch's revision number will be
+> available directly within Python by importing that module. That would
+> allow it to be output in some UI, if that's what you're interested in
+> seeing.
+
+True. Which means that whichever version string wins out, the other
+side will still be able to access the info we both want included ;).
+We can certainly suggest that bug reporters submit their
+ be --verbose-version
+when they submit bugs. The only role of the official "version string"
+is to make life easy for packagers. If they woln't be switching
+branches, then either of our proposals are fine. If they will, then
+I think timestamps work better.
+
+--
+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
--- /dev/null
+Alt-id: <20090716103855.GA8579@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 16 Jul 2009 06:38:55 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: fdb615a4-168a-467b-8090-875c998455e5
+
--- /dev/null
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > "W. Trevor King" <wking@drexel.edu> writes:
+> >
+> > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > Please, no. Timestamps aren't version strings, that's conflating
+> > > > two pieces of information with very different meanings.
+> > > > Correlating the two is the job of a [NEWS file].
+>
+> > If you want a monotonically-increasing indicator of which revision
+> > we're up to, that's immediately available with the revision number
+> > from VCS on the main branch. That also has the advantage of
+> > producing consecutive numbers for each revision, by definition.
+>
+> But not during branch-switches, while my method skips large regions,
+> but probably increases during any reasonable branch-switch.
+
+I've read this several times now, and I don't see what it's saying.
+
+The assumption I'm making is that there is a single canonical “main
+branch”, from which releases will be made. The version number set in
+that branch is the one which determines the version of Bugs Everywhere
+as a whole.
+
+The revision number is only useful in the context of the branch, so it
+only matters when comparing versions within a branch. When you switch
+between branches, if you're interested in the revision number you'll
+still need to know which branch you're talking about.
+
+Switching between branches doesn't change the canonical version string.
+
+> For example, when I upgraded to rich root to pull Ben's patch, I'm not
+> sure if Chris upgraded the trunk and merged my branch, or just ditched
+> the trunk and cloned my branch. Using actual bzr revision numbers
+> would make switching branches that either wrong (in the case of rev-id
+> decreases) or confusing (in the case of a single non-consecutive
+> increase).
+
+This, then, is an argument for not having the revision number in the
+version string at all. The version then becomes a more traditional
+“major.minor.patch” tuple, and is only ever updated when some release
+manager of the canonical branch decides it's correct to do so.
+
+If we use the ‘bzr version-info --format=python > foo_version.py’
+command in some build routine, the branch's revision number will be
+available directly within Python by importing that module. That would
+allow it to be output in some UI, if that's what you're interested in
+seeing.
+
+--
+ \ “Never do anything against conscience even if the state demands |
+ `\ it.” —Albert Einstein |
+_o__) |
+Ben Finney
--- /dev/null
+Alt-id: <87d481ht1s.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 16 Jul 2009 19:32:31 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
--- /dev/null
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > Please, no. Timestamps aren't version strings, that's conflating two
+> > pieces of information with very different meanings. Correlating the
+> > two is the job of a changelog.
+>
+> Which we don't bother keeping (also NEWS), since "bzr log" works so
+> nicely.
+
+That's not a changelog, that's a commit log of every source-level commit
+made. Far too much detail for a changelog of *user-visible* changes
+associated with a release.
+
+> The timestamp should at least replace the patch release number, which
+> you agree is-desirable-to increase motonically ;).
+
+I still disagree that a timestamp is the right thing to use there. If
+you want a monotonically-increasing indicator of which revision we're up
+to, that's immediately available with the revision number from VCS on
+the main branch. That also has the advantage of producing consecutive
+numbers for each revision, by definition.
+
+> One problem is that we don't actually have "releases". People just
+> clone a branch, install, and go.
+
+I agree that's a problem. I think the solution is to start making
+releases, with specific version strings, as source tarballs.
+
+James Rowe <jnrowe@gmail.com> writes:
+
+> Isn't there a bzr web interface that at least supports creating
+> tarballs/zips?
+
+Even better: ‘bzr export /tmp/foo.tar.gz’ will create a source tarball
+of all the files in the branch's VCS inventory. All we need to do is
+start the practice of tagging a release in the VCS, and export the
+tarball at that time.
+
+--
+ \ “Pinky, are you pondering what I'm pondering?” “Well, I think |
+ `\ so (hiccup), but Kevin Costner with an English accent?” —_Pinky |
+_o__) and The Brain_ |
+Ben Finney
--- /dev/null
+Alt-id: <87k52bjoxe.fsf_-_@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Wed, 15 Jul 2009 00:54:05 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
--- /dev/null
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: W. Trevor King <wking@drexel.edu>
+
+
+severity: wishlist
+
+
+status: open
+
+
+summary: How should we version BE?
+
+
+time: Tue, 21 Jul 2009 17:19:22 +0000
+
--- /dev/null
+Hi,
+
+ > http://bitbucket.org/sjl/cherryflavoredbugseverywhere/
+
+Cool! I've set up a copy here:
+
+ http://bugsweb.bugseverywhere.org/
+
+(Since we don't have any open bugs lately, click "Closed" at the top,
+or create some, but don't expect them to persist if you do.)
+
+ > anyone has any feedback (on any aspect of it) I'd appreciate it.
+
+I'm pretty enthusiastic about merging this and then working on it
+further.
+
+Thanks,
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <m3eisxtgfx.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Fri, 03 Jul 2009 20:55:30 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: 2496ccca-130b-4459-bfae-9d9ef0138177
+
--- /dev/null
+Hi everyone. I found Bugs Everywhere and really like the idea of
+distributed bug tracking. I felt like practicing building a CherryPy
+site so I put together a quick web interface to BE. I know there's
+already a TurboGears one in the works, but I needed an excuse to try
+out CherryPy again after working with Django for a while.
+
+Would any of you be willing to take a look at what I've got so far and
+tell me what you think I could improve?
+
+To install and use it:
+
+* Install CherryPy from http://cherrypy.org/ if you don't have it.
+* Install Jinja2 from http://jinja.pocoo.org/2/ if you don't have it.
+* Install BugsEverywhere - you probably know how to do this :)
+* Download a zip/tar of my project (or hg clone) from http://bitbucket.org/sjl/cherryflavoredbugseverywhere/
+* Unzip my project and put the folder in your Python site-packages
+directory.
+* Symlink site-packages/cherryflavoredbugseverywhere/cfbe.py to /usr/
+local/bin/cfbe
+* Use the "cfbe [project_root]" command to start up the web interface
+for that project.
+* Visit http://localhost:8080/ in a browser.
+
+I know that's a lot of steps. I'd like to streamline it quite a bit,
+but first I wanted to see if you have any feedback on the system
+itself. Thanks!
+
+--
+Steve Losh
+http://stevelosh.com/
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <272FECFE-D16B-47B7-B39A-E2C8A718CCC5@stevelosh.com>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 07 Feb 2009 16:30:33 -0500
+
+
+From: Steve Losh <steve@stevelosh.com>
+
--- /dev/null
+Those are beautiful templates -- can you share those? I'd love to
+study the HTML and CSS behind them.
+
+On Sat, Feb 7, 2009 at 5:48 PM, Steve Losh <steve@stevelosh.com> wrote:
+> Hey Chris, thanks for the comments.
+>
+>>
+>> My initial impression is that this looks good enough already to merge as
+>> a replacement for the turbogears site. What does everyone else think?
+>>
+>
+> I'm not quite sure it's there yet. There are a bunch of bugs I've got
+> marked as "beta" that I'd like to see fixed before it's ready for real use.
+> Hopefully they shouldn't be too tough to fix. You can point CFBE at itself
+> to see them. :)
+>
+>> Could you explain a little about how you handle authorship of bug
+>> changes at the moment, and if it looks plausible to try making it
+>> multiuser? (Having it handle more than one "user" logged in at once.)
+>>
+>
+> That's something I need advice on. Right now CFBE is pretty much only
+> suitable for local use - you check out whatever you're working on and use it
+> as a local interface to the bugs in the repository. Change those, check in,
+> etc. It's effectively just a pretty version of the command line be tool.
+>
+> I haven't used CherryPy's session/authentication support before. This might
+> be a good time for me to learn. One way it might be able to handle multiple
+> users hitting a central server:
+>
+> * Each user has to register with the server and be approved by an admin.
+> * Each account would be mapped to a contributor string, the same one that
+> would show up if you were going to commit to the repository.
+> * Once you have an account, you'd login to make any changes.
+>
+>
+> Aside from all that, I'm a little fuzzy on how a centralized interface to a
+> distributed bug tracking system should work. A read-only interface to a
+> central "main" repository would be easy. Run the server in read-only mode
+> pointing at the main repository. People can use it to look at the bugs in
+> the tip of that repository.
+>
+> If it's not read-only, what happens when a user changes/adds/whatevers a
+> bug? Should CFBE commit that change to the repository right then and there?
+> Should it never commit, just update the bugdir and let the commits happen
+> manually?
+>
+> What happens when you have multiple branches for a repository? Should there
+> be one CFBE instance for each branch, or a single one that lets you switch
+> between branches (effectively switching between revisions)?
+>
+> Those are the kind of things that don't really apply when CFBE is just a
+> local interface to a single repository. If anyone has any advice on how a
+> multi-user interface should work I'd love to hear it!
+>
+> --
+> Steve Losh
+> http://stevelosh.com/
+>
+>
+> _______________________________________________
+> Be-devel mailing list
+> Be-devel@bugseverywhere.org
+> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
+>
+
+
+
+--
+Matthew Wilson
+matt@tplus1.com
+http://tplus1.com
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <f6f643a20902071531y6aa3d7a6k7c5a4bd4aa5a04f6@mail.gmail.com>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 07 Feb 2009 18:31:04 -0500
+
+
+From: Matthew Wilson <matt@tplus1.com>
+
+
+In-reply-to: 21c90231-d7f2-49bb-97d9-99e16459d799
+
--- /dev/null
+Hey Chris, thanks for the comments.
+
+>
+> My initial impression is that this looks good enough already to
+> merge as
+> a replacement for the turbogears site. What does everyone else think?
+>
+
+I'm not quite sure it's there yet. There are a bunch of bugs I've got
+marked as "beta" that I'd like to see fixed before it's ready for real
+use. Hopefully they shouldn't be too tough to fix. You can point
+CFBE at itself to see them. :)
+
+> Could you explain a little about how you handle authorship of bug
+> changes at the moment, and if it looks plausible to try making it
+> multiuser? (Having it handle more than one "user" logged in at once.)
+>
+
+That's something I need advice on. Right now CFBE is pretty much only
+suitable for local use - you check out whatever you're working on and
+use it as a local interface to the bugs in the repository. Change
+those, check in, etc. It's effectively just a pretty version of the
+command line be tool.
+
+I haven't used CherryPy's session/authentication support before. This
+might be a good time for me to learn. One way it might be able to
+handle multiple users hitting a central server:
+
+* Each user has to register with the server and be approved by an admin.
+* Each account would be mapped to a contributor string, the same one
+that would show up if you were going to commit to the repository.
+* Once you have an account, you'd login to make any changes.
+
+
+Aside from all that, I'm a little fuzzy on how a centralized interface
+to a distributed bug tracking system should work. A read-only
+interface to a central "main" repository would be easy. Run the
+server in read-only mode pointing at the main repository. People can
+use it to look at the bugs in the tip of that repository.
+
+If it's not read-only, what happens when a user changes/adds/whatevers
+a bug? Should CFBE commit that change to the repository right then
+and there? Should it never commit, just update the bugdir and let the
+commits happen manually?
+
+What happens when you have multiple branches for a repository? Should
+there be one CFBE instance for each branch, or a single one that lets
+you switch between branches (effectively switching between revisions)?
+
+Those are the kind of things that don't really apply when CFBE is just
+a local interface to a single repository. If anyone has any advice on
+how a multi-user interface should work I'd love to hear it!
+
+--
+Steve Losh
+http://stevelosh.com/
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <D765386C-4D43-4AE0-83E3-986A1CB4008C@stevelosh.com>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 07 Feb 2009 17:48:06 -0500
+
+
+From: Steve Losh <steve@stevelosh.com>
+
+
+In-reply-to: 42d57a41-219f-46db-9fda-21b42351da63
+
--- /dev/null
+Speaking of that interface, I changed up the look and feel a bit last
+weekend. It's still at http://bitbucket.org/sjl/cherryflavoredbugseverywhere/
+ -- if anyone has any feedback (on any aspect of it) I'd appreciate it.
+
+--
+Steve
+
+On Jul 3, 2009, at 8:31 PM, Chris Ball wrote:
+
+> Hi Gianluca,
+>
+>> As i said in a previous mail, I am working on a "html" command
+>> for be. The goal is to be able to do something like "be html
+>> /web/page" to have in the /web/page directory some static html
+>> pages that basically are the dump of the be repository, much like
+>> ditz have. This will enable a simple and fast publish of the bus
+>> list and details on the web, at least in read only mode.
+>
+> It might be a good idea for "be html" to use the CherryPy web
+> interface
+> that Steve is working on. The command could start up the CherryPy app
+> and scrape all of the available pages to get a stand-alone dump; this
+> would avoid having to keep two (okay, more than two at this point)
+> separate sets of HTML templates in the source tree. What do you
+> think?
+>
+>> 2) I see that every command is implemented with a python file in
+>> the becommand dir. For a better code, I'd like to split the
+>> command implementation into two files: a file that contain the
+>> actual code and a second file that have the html related part,
+>> any problem with this ? I don't like to have the html part and
+>> the code part in one big and unreadable file.
+>
+> I agree that becommands/*.py commands should not contain any HTML
+> layout code. Putting it somewhere else instead sounds fine.
+>
+> Thanks!
+>
+> - Chris.
+> --
+> Chris Ball <cjb@laptop.org>
+>
+> _______________________________________________
+> Be-devel mailing list
+> Be-devel@bugseverywhere.org
+> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <4701D71B-A14D-4C63-ABCC-E7E5FFE4E4BA@stevelosh.com>
+
+
+Content-type: text/plain
+
+
+Date: Fri, 03 Jul 2009 20:34:51 -0400
+
+
+From: Steve Losh <steve@stevelosh.com>
+
+
+In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d
+
--- /dev/null
+Hi Steve,
+
+ > Hi everyone. I found Bugs Everywhere and really like the idea of
+ > distributed bug tracking. I felt like practicing building a
+ > CherryPy site so I put together a quick web interface to BE. I
+ > know there's already a TurboGears one in the works, but I needed an
+ > excuse to try out CherryPy again after working with Django for a
+ > while.
+
+This looks awesome, thanks! I've taken some screenshots for others to
+see:
+
+http://chris.printf.net/cfbe-main.png
+http://chris.printf.net/cfbe-detail.png
+
+My initial impression is that this looks good enough already to merge as
+a replacement for the turbogears site. What does everyone else think?
+
+Could you explain a little about how you handle authorship of bug
+changes at the moment, and if it looks plausible to try making it
+multiuser? (Having it handle more than one "user" logged in at once.)
+
+Great work, thanks!
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
--- /dev/null
+Alt-id: <m3zlgxyjo5.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 07 Feb 2009 17:19:22 -0500
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d
+
--- /dev/null
+Hi,
+
+ > Works for me. I've done this now, which closes the last open bug
+ > in my repo :D.
+
+Wow. Congrats! I've merged your branch.
+
+ > All the new functionality comes from bug.extra_strings, which
+ > provides a list for storing arbitrary strings in the bug's
+ > permanent state.
+
+That's going to be really useful.
+
+ > Next up: regexp searching for list --extra-strings! ;).
+
+Awesome.
+
+ > Oh, and obviously there must still be bugs in BE. Please submit
+ > more ;).
+
+Perhaps it's a good time to merge Steve Losh's CherryPy web interface?
+
+http://void.printf.net/pipermail/be-devel/2009-February/000095.html
+http://bitbucket.org/sjl/cherryflavoredbugseverywhere/
+
+Thanks,
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
--- /dev/null
+Alt-id: <m31vp82yyj.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 25 Jun 2009 10:02:44 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d
+
--- /dev/null
+On Jun 25, 2009, at 10:02 AM, Chris Ball <cjb@laptop.org> wrote:
+>
+>> Oh, and obviously there must still be bugs in BE. Please submit
+>> more ;).
+>
+> Perhaps it's a good time to merge Steve Losh's CherryPy web interface?
+>
+> http://void.printf.net/pipermail/be-devel/2009-February/000095.html
+> http://bitbucket.org/sjl/cherryflavoredbugseverywhere/
+>
+
+Hey, I haven't touched the web interface in a while, but I should have
+some time to fix some stuff up tonight and tomorrow. Hold off on
+merging it in until then.
+
+I'm still curious as to what people think the role of a web interface
+like this should be. When I wrote it I meant it as a single-user
+interface like the command line one. It could definitely work as a
+public, read-only interface too.
+
+If the goal is to allow more than one person to add issues, how should
+commits go? One commit per change? Commit every X minutes if necessary?
+
+--
+Steve
--- /dev/null
+Alt-id: <26FBD153-39C5-4641-AF5E-749731964086@stevelosh.com>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 25 Jun 2009 10:23:04 -0400
+
+
+From: Steve Losh <steve@stevelosh.com>
+
+
+In-reply-to: 5e339bac-f4f3-407b-974a-b88795d3573b
+
--- /dev/null
+On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote:
+>> My initial impression is that this looks good enough already to merge as
+>> a replacement for the turbogears site. What does everyone else think?
+>
+> I'm not quite sure it's there yet. There are a bunch of bugs I've
+> got marked as "beta" that I'd like to see fixed before it's ready
+> for real use. Hopefully they shouldn't be too tough to fix. You
+> can point CFBE at itself to see them. :)
+
+Steve's also versioning it with Mercurial. Will he mind changing to
+Bazaar?
+
+Steve, I've touched up CFBE to work with my current BE branch. Some
+of the changes apply to the trunk BE, and hopefully the rest will
+soon. I think the version-naming issue is what's currently blocking
+their adoption ;). I've put up my CFBE branch at
+ static-http://www.physics.drexel.edu/~wking/code/hg/cfbe
+for Mercurial.
+
+Everyone, should CFBE-specific discussions move off-list? More
+generally, I've been sending in lots of what-I'm-working on messages,
+but not hearing much back, so let me know if I'm being too obnoxious,
+and I'll shut up (or at least move more off-list) ;).
+
+Cheers,
+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
--- /dev/null
+Alt-id: <20090721135907.GB4469@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 21 Jul 2009 09:59:07 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 21c90231-d7f2-49bb-97d9-99e16459d799
+
--- /dev/null
+On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote:
+> I'm still curious as to what people think the role of a web interface like
+> this should be. When I wrote it I meant it as a single-user interface like
+> the command line one. It could definitely work as a public, read-only
+> interface too.
+
+I think the multi-user/public is the way to go. I'd also like to see
+a procmail-able script to handle multi-user/public access via email,
+which would have all the same issues we're worrying about here.
+
+On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote:
+> I haven't used CherryPy's session/authentication support before. This
+> might be a good time for me to learn. One way it might be able to handle
+> multiple users hitting a central server:
+>
+> * Each user has to register with the server and be approved by an admin.
+> * Each account would be mapped to a contributor string, the same one that
+> would show up if you were going to commit to the repository.
+> * Once you have an account, you'd login to make any changes.
+
+This sounds good to me. Yay spam reduction ;).
+
+> If it's not read-only, what happens when a user changes/adds/whatevers a
+> bug? Should CFBE commit that change to the repository right then and
+> there? Should it never commit, just update the bugdir and let the commits
+> happen manually?
+
+On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote:
+> One commit per change? Commit every X minutes if necessary?
+
+On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote:
+> What happens when you have multiple branches for a repository? Should
+> there be one CFBE instance for each branch, or a single one that lets you
+> switch between branches (effectively switching between revisions)?
+
+There are interesting discussions about the role of distributed
+bugtracking here (I'm sure there are others):
+ http://lwn.net/Articles/281849/
+ http://community.livejournal.com/evan_tech/248736.html
+
+Personally, I've never done much cherry-picking or anything that would
+require me to determine exactly which parts of someone's work I want
+and which I don't want. I just merge someone's head and edit out the
+bits I don't like, a process that also works well for our current
+"commit however you want" BE development model ;). Maybe that just
+shows that I only work on minor branches of small projects :p. In the
+absence of big-project advice, I think we just limit the web front end
+to our current model, and let the web interface commit however it
+wants as well ;). +1 for adding a <commit> button to the web
+interface ;).
+
+One caveat about a multi-user interface would be that it would allow
+the casual users to commit bugs about whatever version they had
+installed onto the head of the public-bug branch. In order to figure
+out what version of the project they were talking about, the project
+should have a way for the user to get a unique version string, ideally
+be the bzr-revision-id/git-commit/etc. of the commit for the version
+they were using. This would allow developers to determine what branch
+to work on with the bug fix, and what branches needed to pull the
+eventual fix. If the initially reported buggy version wasn't actually
+the root of the bug, oh well :p. Material for a later related bug
+report or a reopen.
+
+--
+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
--- /dev/null
+Alt-id: <20090625154734.GA19441@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 25 Jun 2009 11:47:34 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d
+
--- /dev/null
+assigned: Steve Losh <steve@stevelosh.com>
+
+
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: Steve Losh <steve@stevelosh.com>
+
+
+severity: wishlist
+
+
+status: assigned
+
+
+summary: CherryPy interface "Cherry-flavored BE"
+
+
+time: Tue, 21 Jul 2009 18:52:44 +0000
+
--- /dev/null
+On Thu, Jul 16, 2009 at 09:39:30AM -0400, W. Trevor King wrote:
+> Disclaimer: I imaging the current implementation will choke on
+> non-text/plain content types. Also possibly on non-ascii encodings.
+
+Non-ascii encodings are now handled (although now the output is
+base64-encoded). This is limited by poor unicode handling in the
+email module for current pythons, see the log for more details.
+
+> I should probably allow the "help" command ... ;).
+
+Added, but it currently shows _all_ commands, not just allowed
+commands.
+
+--
+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
--- /dev/null
+Alt-id: <20090718131220.GA31832@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 09:12:20 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: f1cde826-0506-4b4a-92ab-8499e953fa49
+
--- /dev/null
+On Sat, Jul 18, 2009 at 06:05:51PM -0400, W. Trevor King wrote:
+> My email interface now supports bug creation/comments that look
+> like:
+>
+> $ cat | mail -s "[be-bug] new" "whatever-dev@fancyprojects.com"
+> The demuxulizer is broken
+>
+> <describe bug>
+> ^D
+
+The move towards the DBT interface means this example should now look
+like
+
+ $ cat | mail -s "[be-bug:submit] The demuxulizer is broken" whatever-dev@fancyprojects.com
+ Version: XYZ
+
+ <describe bug>
+ --
+ Ignored text
+ ^D
+
+--
+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
--- /dev/null
+Alt-id: <20090719130649.GA4164@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 19 Jul 2009 09:06:49 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 7b904395-86e9-4eb1-8534-69cec63801d4
+
--- /dev/null
+Ah, it's been a good day :). My email interface now supports bug
+creation/comments that look like:
+
+ $ cat | mail -s "[be-bug] new" "whatever-dev@fancyprojects.com"
+ The demuxulizer is broken
+
+ <describe bug>
+ ^D
+
+Which is probably easy enough for just about anybody ;). Also easy
+for other projects to wrap into one of their tools:
+
+ $ cat | projectAexecutable --report-bug
+ The demuxulizer is broken
+
+ <describe bug>
+ ^D
+
+Which could do things like automatically add the version string, OS
+name, etc.
+
+--
+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
--- /dev/null
+Alt-id: <20090718220551.GB32230@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 18:05:51 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 09f950d4-9366-4e7b-98b3-9057999f8f38
+
--- /dev/null
+On Sun, Jul 19, 2009 at 09:09:05AM +1000, Ben Finney wrote:
+> > The interface is basically "place your be command in the subject line"
+>
+> I would far prefer an interface of “place as many BE commands as you
+> like at the top of the message body, ending with an optional terminator
+> command, and they will each be executed in turn”.
+> ...
+
+I think the idea behind my first approach was "you guys have
+experience with the command line BE interface, so it will be easier to
+test if you don't have to learn the DBT interface." The Debian people
+have been doing this for a while though, so I imagine their email
+interface is pretty good ;).
+
+Here's a short primer on my take on the DBT interface.
+
+The DBT has three main email addresses, each with it's own parsing style.
+ 1) creating bugs (submit@bugs.debian.org)
+ 2) commenting on bugs (<bug-number>@bugs.debian.org)
+ 3) controlling/managing bugs (control@bugs.debian.org)
+I'm trying to squeeze these down into a single email address to avoid
+having to tinker with the mail delivery system, so I've got everything
+at (wking at tremily dot us) with subject tags:
+ 1) creating bugs
+ Subject: [be-bug:submit] new bug summary ...
+ 2) commenting on bugs
+ Subject: [be-bug:<bug-number>] human-specific subject
+ 3) control
+ Subject: [be-bug] human-specific subject
+
+The parsing styles each follow their DBT counterparts, but currently
+have a much restricted breadth.
+
+The control-style consists of a list of allowed be commands, with one
+command per line. Blank lines and lines beginning with '#' are
+ignored, as well anything following a line starting with '--'. All the
+listed commands are executed in order and their output returned.
+
+The comment-style interface appends a comment to the bug specified in
+the subject tag. The the first non-multipart body is attached with
+the appropriate content-type. In the case of "text/plain" contents,
+anything following a line starting with '--' is stripped.
+
+The create-style interface creates a bug whose summary is given by the
+email's post-tag subject. The body of the email must begin with a
+psuedo-header containing at least the "Version" field. Anything after
+the pseudo-header and before a line starting with '--' is, if present,
+attached as the bugs first comment.
+
+Take a look at my interfaces/email/interactive/examples for some
+examples.
+
+--
+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
--- /dev/null
+Alt-id: <20090719130153.GA4036@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 19 Jul 2009 09:01:53 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: cfd7cbc7-27ad-4618-8530-cb4d7323514a
+
--- /dev/null
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> The interface is basically "place your be command in the subject line"
+
+I would far prefer an interface of “place as many BE commands as you
+like at the top of the message body, ending with an optional terminator
+command, and they will each be executed in turn”.
+
+This would allow a single message to perform a batch of BE commands that
+are related, instead of requiring to send each command in a separate
+message.
+
+It would also leave the subject field free for something more
+descriptive. The subject field could also be used as the summary field
+of newly-created bug reports. With a terminator command, this would
+allow the message to be sent both to BE and to some other recipient
+(e.g. a mailing list) explaining the change.
+
+Have a look at the email interface of the Debian BTS for an example
+<URL:http://www.debian.org/Bugs/server-request>.
+
+--
+ \ “Pinky, are you pondering what I'm pondering?” “Wuh, I think |
+ `\ so, Brain, but will they let the Cranberry Duchess stay in the |
+_o__) Lincoln Bedroom?” —_Pinky and The Brain_ |
+Ben Finney
--- /dev/null
+Alt-id: <87fxctbnce.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Sun, 19 Jul 2009 09:09:05 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: f1cde826-0506-4b4a-92ab-8499e953fa49
+
--- /dev/null
+I finally did something towards a useful interactive email interface
+;). As per our new guidelines, I'll develop this feature in it's own
+branch:
+ http://www.physics.drexel.edu/~wking/code/bzr/be-email
+
+The interface is basically "place your be command in the subject line"
+with a few exceptions. Some examples:
+ Subject: [be-bug] list --status=all
+ Subject: [be-bug] show --xml ID
+ Subject: [be-bug] new
+ Subject: [be-bug] comment ID
+In the case of "new", the bug description is extracted from the first
+non-blank body line. In the case of "comment", the email body is used
+as the comment. Currently only "list", "show", "new", and "comment"
+are allowed.
+
+You should get a reply email with exit status, stdout, and stderr from
+your command.
+
+Send some mail to [wking (at) tremily (dot) us] to try it out! Depending
+on spam attraction, this might be a limited time offer ;).
+
+Hopefully this lowers the entry barrier for bug reporting :).
+
+Disclaimer: I imaging the current implementation will choke on
+non-text/plain content types. Also possibly on non-ascii encodings.
+Probably lots of other bugs too... ;). For example, I should probably
+allow the "help" command ... ;).
+
+Cheers,
+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
--- /dev/null
+Alt-id: <20090716133930.GC12213@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 16 Jul 2009 09:39:30 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
--- /dev/null
+Hi Trevor,
+
+ > I finally did something towards a useful interactive email
+ > interface ;).
+
+Wow, nice! That'll be really useful.
+
+- Chris.
+--
+Chris Ball <cjb@laptop.org>
--- /dev/null
+Alt-id: <m3fxct5vl6.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 21:07:33 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: f1cde826-0506-4b4a-92ab-8499e953fa49
+
--- /dev/null
+assigned: W. Trevor King <wking@drexel.edu>
+
+
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: W. Trevor King <wking@drexel.edu>
+
+
+severity: wishlist
+
+
+status: assigned
+
+
+summary: Interactive email interface
+
+
+time: Tue, 21 Jul 2009 18:53:50 +0000
+
projects / be.git / commitdiff