diff options
18 files changed, 288 insertions, 5 deletions
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/comments/ba96f1c0-ba48-4df8-aaf0-4e3a3144fc46/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/comments/ba96f1c0-ba48-4df8-aaf0-4e3a3144fc46/body new file mode 100644 index 0000000..288fc29 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/comments/ba96f1c0-ba48-4df8-aaf0-4e3a3144fc46/body @@ -0,0 +1,11 @@ +It would be nice if we could store tests. + .be/BUGDIR/tests/... +and link them from bugs. + +Then running + test.py BUGDIR/BUG +would run the tests for that particular bug. + +This would provide regression testing via + test.py $(be list --ids --status fixed) + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/comments/ba96f1c0-ba48-4df8-aaf0-4e3a3144fc46/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/comments/ba96f1c0-ba48-4df8-aaf0-4e3a3144fc46/values new file mode 100644 index 0000000..691163d --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/comments/ba96f1c0-ba48-4df8-aaf0-4e3a3144fc46/values @@ -0,0 +1,8 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sun, 03 Jan 2010 16:32:13 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/values new file mode 100644 index 0000000..4d7cd5c --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/3438b72c-6244-4f1d-8722-8c8d41484e35/values @@ -0,0 +1,11 @@ +severity: minor + + +status: open + + +summary: Attach tests to bugs + + +time: Sun, 03 Jan 2010 16:23:42 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/17d045d1-3b21-4d3d-8f81-29a5bbc5e6c1/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/17d045d1-3b21-4d3d-8f81-29a5bbc5e6c1/body new file mode 100644 index 0000000..6e3f1e7 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/17d045d1-3b21-4d3d-8f81-29a5bbc5e6c1/body @@ -0,0 +1,14 @@ +> Roundup's great strength is the flexibility of its data model and +> range of generic support. It's very easy to extend... +> ... +> As far as postponed customization goes, it would be easy enough to +> duplicate Roundup's schema.py and provide a default schema.py for +> bugtracking. This would improve our current system by keeping all the +> configurable bits under version control from the start (equivalent to +> setting _versioned_property(require_save=True) for all properties). + +How will we handle diffs between with revisions with different +schema.py? This re-raises #bea86499-824e-4e77-b085-2d581fa9ccab/ed5eac05-80ed-411d-88a4-d2261b879713/c664b7be-ded5-42dd-a16a-82b2bdb52e36# (#bea86499-824e-4e77-b085-2d581fa9ccab/1100c966-9671-4bc6-8b68-6d408a910da1/bd1207ef-f97e-4078-8c5d-046072012082#), but we +_expect_ schema.py to evolve, while before we had expected on-disk +versions to stabilize. + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/17d045d1-3b21-4d3d-8f81-29a5bbc5e6c1/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/17d045d1-3b21-4d3d-8f81-29a5bbc5e6c1/values new file mode 100644 index 0000000..5bc6769 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/17d045d1-3b21-4d3d-8f81-29a5bbc5e6c1/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sun, 03 Jan 2010 16:02:57 +0000 + + +In-reply-to: d463e2d9-6dcc-41a4-a6b2-647fb3bddf88 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/d463e2d9-6dcc-41a4-a6b2-647fb3bddf88/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/d463e2d9-6dcc-41a4-a6b2-647fb3bddf88/body new file mode 100644 index 0000000..b953536 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/d463e2d9-6dcc-41a4-a6b2-647fb3bddf88/body @@ -0,0 +1,67 @@ +The Roundup issue tracker + http://roundup.sourceforge.net/ +has been around for a while, and provides a nice, flexible design + http://roundup.sourceforge.net/docs/design.html +What ideas from Roundup are worth incorperating in our setup? + +Roundup's great strength is the flexibility of its data model and +range of generic support. It's very easy to extend. However, there +is only so far you can go with generic support. Roundup lacks analogs +to the following Command subclasses (as far as I know): + Diff + Has per-issue logs, but no repository-wide summary + Merge + Commit + No VCS backends, see http://issues.roundup-tracker.org/issue2550547 + Import_xml + Serve + Has HTML server, but no remote command-line access +Of course, none of these would be particularly hard to add to Roundup, +with the possible exception of VCS backends, which appears to be +in-progress anyway. However, I really like the simplicity of + `be init` +and the ability to postpone repository customization until you need +it. So, can we trim down the BE internals to make BE more extensible +without sacrificing our nice default setup and its tools? The problem +is, how to the commands do their thing if they don't know what they're +working with? + +Say, for example, I want to run `be depend bugA bugB`, but my bugs +don't have blocks or blocked_by link properties. That could be easily +handled by having each command would have to keep track of which +properties it needed and raise appropriate exceptions. + +List, Show, Import_xml, etc. would presumably use templates to define +their output/input formats. + +As far as postponed customization goes, it would be easy enough to +duplicate Roundup's schema.py and provide a default schema.py for +bugtracking. This would improve our current system by keeping all the +configurable bits under version control from the start (equivalent to +setting _versioned_property(require_save=True) for all properties). + +Another part of the difference between BE and Roundup seems to be due +to the initial backend selection. Roundup is built on databases, +which encourages their keyed-Class approach with (property, value) +pairs of predefined types. They use Classes for everything, down to +status values, etc., while we've built those sorts of things into +_versioned_property()s. +Benefits of Roundup approach: + * easy to configure/alter/retrieve list of allowed values + * no need to hard-code properties or resort to extra_strings + * assigned values are actually links to centralized definitions + - easy updates +Benefits of BE approach: + * single file for all properties + - one read and you're done + - many file systems don't handle 'lots of tiny files' well + * assigned values are actual values, not links to centralized defs. + - easy to merge by hand, no need to look up references. +Since it would be fairly simple to add a merging tool that handled the +reference lookup transparently, we can move to a Roundup-like Class +structure by using our current mapfile implementation to store small +Classes. + +Finally, would it be easier to merge these Roundup features into BE, +or merge the BE features into Roundup... + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/d463e2d9-6dcc-41a4-a6b2-647fb3bddf88/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/d463e2d9-6dcc-41a4-a6b2-647fb3bddf88/values new file mode 100644 index 0000000..cb7278c --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/comments/d463e2d9-6dcc-41a4-a6b2-647fb3bddf88/values @@ -0,0 +1,8 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sun, 03 Jan 2010 14:16:55 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/values new file mode 100644 index 0000000..9c9a294 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/814e39c0-68ee-4165-9166-19e2aee9c07d/values @@ -0,0 +1,11 @@ +severity: minor + + +status: open + + +summary: Add Roundup-like flexibility + + +time: Sun, 03 Jan 2010 13:12:38 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/body new file mode 100644 index 0000000..ae7a57f --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/body @@ -0,0 +1,21 @@ +> I think a good solution would run along the lines of the currently +> commented out code in duplicate_bugdir(), where a +> VersionedStorage.changed_since(revision) +> call would give you a list of changed files. diff could work off of +> that directly, without the need to generate a whole duplicate bugdir. + +This is definately the way to go. Rough approach for the VCS family: + +1) Parse `bzr diff` or such to get a list of new,changed,moved,removed + paths. +2) Convert those paths to ids. +3) Return a list of ids to duplicate_bugdir(). +4) Provide Storage.parent(id, revision), so duplicate_bugdir() could + figure out what type of id we were dealing with (bugdir, bug, + comment, other?), and construct the appropriate difference tree. + +There could be a DupBugDir class which stored that diff tree and a +link to the current bugdir, which would make diffs much easier (work +already done, just copy the diff tree), and provide faster access to +unchanged files (just use the current version). + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/values new file mode 100644 index 0000000..3dfe992 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sun, 03 Jan 2010 12:25:03 +0000 + + +In-reply-to: 9c4b8921-7b43-4bb6-b650-34144b414dc0 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/body new file mode 100644 index 0000000..e43a951 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/body @@ -0,0 +1,23 @@ +Ok, time to fix the issue I mentioned in this commit message: + +revno: 473.1.63 +revision-id: wking@drexel.edu-20091215114420-sbdnvm5jlx0ampbg + +... +duplicate_bugdir() works, but for the vcs backends, it could require +shelling out for _every_ file read. This could, and probably will, be +horribly slow. Still it works ;). + +I'm not sure what a better implementation would be. The old +implementation checked out the entire earlier state into a temporary +directory + pros: single shell out, simple upgrade implementation + cons: wouldn't work well for HTTP backens + +I think a good solution would run along the lines of the currently +commented out code in duplicate_bugdir(), where a + VersionedStorage.changed_since(revision) +call would give you a list of changed files. diff could work off of +that directly, without the need to generate a whole duplicate bugdir. +I'm stuck on how to handle upgrades though... +... diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/values new file mode 100644 index 0000000..a02a32b --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/values @@ -0,0 +1,8 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 02 Jan 2010 22:58:31 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/body new file mode 100644 index 0000000..b1b9b1a --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/body @@ -0,0 +1,7 @@ +> I'm stuck on how to handle upgrades though... + +I've satisfied myself with the solution mentioned in #bea86499-824e-4e77-b085-2d581fa9ccab/1100c966-9671-4bc6-8b68-6d408a910da1/bd1207ef-f97e-4078-8c5d-046072012082#, +namely, upgrading on disk the way we've always done, and not +supporting on-the-fly upgrading at all. This isn't important for this +bug, but I didn't want to just ignore that part of the commit message. + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/values new file mode 100644 index 0000000..1d01491 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 02 Jan 2010 23:04:01 +0000 + + +In-reply-to: 9c4b8921-7b43-4bb6-b650-34144b414dc0 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/values new file mode 100644 index 0000000..172458c --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/values @@ -0,0 +1,11 @@ +severity: minor + + +status: open + + +summary: Slow and ugly diff implementation + + +time: Sat, 02 Jan 2010 22:56:08 +0000 + @@ -1,3 +1,7 @@ +January 3, 2010 + * Changed `be list --uuids` -> `be list --ids` + Instead of UUIDs, it now outputs user ids: BUGDIR/BUG + January 1, 2010 * Added HTTP storage backend and server Serve a local repo on http://localhost:8000 diff --git a/doc/distributed_bugtracking b/doc/distributed_bugtracking new file mode 100644 index 0000000..1164c14 --- /dev/null +++ b/doc/distributed_bugtracking @@ -0,0 +1,46 @@ +Usage Cases +=========== + +Case 1: Tracking the status of bugs in remote repo branches +----------------------------------------------------------- + +See discussion in + #bea86499-824e-4e77-b085-2d581fa9ccab/12c986be-d19a-4b8b-b1b5-68248ff4d331# +Here, it doesn't matter whether the remote repository is a branch of +the local repository, or a completely separate project +(e.g. upstream, ...). So long as the remote project provides access +via some REPO format, you can use + be --repo REPO ... +to run your query, or + be diff REPO +to see the changes between the local and remote repositories. + + +Case 2: Importing bugs from other repositories +---------------------------------------------- + +Case 2.1: If the remote repository is a branch of the local repository + VCS merge REPO +Case 2.2: If the remote repository is not a branch of the local repository + Hypothetical command: + be import REPO ID + + +Notes +===== + +Providing public repositories +----------------------------- + +e.g. for non-dev users. These are just branches that expose a public +interface (HTML, email, ...). Merge and query like any other +development branch. + + +Managing permissions +-------------------- + +Many bugtrackers implement some sort of permissions system, and they +are certainly required for a central system with diverse user roles. +However DVCSs also support the 'pull my changes' workflow, where +permissions are irrelevant. diff --git a/libbe/command/list.py b/libbe/command/list.py index 8b5cb4e..8baeaa2 100644 --- a/libbe/command/list.py +++ b/libbe/command/list.py @@ -108,14 +108,14 @@ class List (libbe.command.Command): arg=libbe.command.Argument( name='sort', metavar='SORT', default=None, completion_callback=libbe.command.util.Completer(AVAILABLE_CMPS))), - libbe.command.Option(name='uuids', short_name='u', - help='Only print the bug UUIDS'), + libbe.command.Option(name='ids', short_name='i', + help='Only print the bug IDS'), libbe.command.Option(name='xml', short_name='x', help='Dump output in XML format'), ]) # parser.add_option("-S", "--sort", metavar="SORT-BY", dest="sort_by", # help="Adjust bug-sort criteria with comma-separated list SORT-BY. e.g. \"--sort creator,time\". Available criteria: %s" % ','.join(AVAILABLE_CMPS), default=None) -# # boolean options. All but uuids and xml are special cases of long forms +# # boolean options. All but ids and xml are special cases of long forms # ("w", "wishlist", "List bugs with 'wishlist' severity"), # ("i", "important", "List bugs with >= 'serious' severity"), # ("A", "active", "List all active bugs"), @@ -151,9 +151,9 @@ class List (libbe.command.Command): bugs = self._sort_bugs(bugs, cmp_list) # print list of bugs - if params['uuids'] == True: + if params['ids'] == True: for bug in bugs: - print >> self.stdout, bug.uuid + print >> self.stdout, bug.id.user() else: self._list_bugs(bugs, xml=params['xml']) bugdir.storage.writeable = writeable |