Forum OpenACS Development: Software Development (Bugs, QA, etc) and OACS

Hey guys,

Having just looked through some sites regarding SCM because of the discussion regarding the beta, the fact that there's no real SDM in OACS4.5 and due to some of my thoughts for the new OACS site (specifically a developer.openacs.org which I mentioned in a thread a few months ago), I would like to start a discussion of how we can address a system that is either for or in the new toolkit.

I know that there are some people out there that have thought about what a new system might look like (namely Carl Coryell-Martin and a fellow whom I met at the SF social named Alan, IIRC). I think both of them have looked at both ticket-tracker and SDM as a solution. I also know that Gilbert also posted a call to the bboards about possibly looking to build a software development package using OACS.

One question that should be asked is whether the community might abandon trying to build this kind of application all together. Ben did a great job with SDM and it's an amazing starting template for a new system. However, it's in the old toolkit and no one seems to be continuing to work on it.

Also, rather than just porting the code to OACS4 it seems (based on some conversations with others) that it's better to start all over and write a new system using nice OACS4.x pieces like workflow and/or subsites.

However, I would also hope we're not overcome by NIH syndrome. There are some decent pieces of code out there that are probably not as good as what can be built using OACS4.x, but they are already built.

So the first question to ask is whether there is community interest and justification for building another open source development manager. The solution to this might be using another system, porting SDM to OACS4 or just continuing to use SDM in OACS3.x

If the answer is yes (and I do expect that it will be), then I suggest we use this thread as a call for a feature list of items for what we might want. This includes some of the following items that are important for the OACS project, but also would be tremendously helpful for vendors or consultants servicing clients (many of which come from what I need for my clients):

  • Bug tracking and bug assignment
  • Feature requests
  • QA and assignment
  • Support requests and assignment
  • SCM integration (either tied to CVS or abstracted to work with any SCM tool like Subversion, Perforce or Bitkeeper)
I think this is a very general list so I hope that others have ideas that they can add.

talli

Collapse
Posted by Don Baccus on
Well ... a new SDM tied to a new Intranet-ish suite tied to a knowledge management system would be a very interesting thing.

In other words the old intranet package gave some control over how you can let people (clients) into the system, controlling what they can see and can't see, what they can and can't do, etc.  Tie that with the SDM and you'd have something more useful for small consulting companies than bugzilla, I think, due to the nice possibilities that the rich OpenACS 4 datamodel makes possible.

And given that there are several small consulting companies in the community that would be nice, no?

And combined with the new portal package users would have a high degree of portal customization at their fingertips, too.

So ... obviously something like this in OpenACS 4 could be a world-class piece of software that might really enhance our visibility if it became at all possible.

The rub - resources.  Where are the resources to take on something as ambitious as this?

I would definately like to see the SDM modernized. Sure, it needs some
hooks into the newer modules, but the core of the SDM seems pretty
solid. It's better than most other systems I've used.

In other words, I'd vote to start with the SDM design, and work from
there.

Well, the SDM is pretty nice, and as usual, the datamodel is the nicest part of it. Yes it can be improved, but that's (usually) easier than starting from scratch.

Has anybody looked at the 4.x port of SDM that ArsDigita made?

Collapse
Posted by Dave Bauer on
I found a copy of the 4.x SDM over at the ybos repository and I downloaded it. It is Oracle only, and appears to just be the 3.x files in an APM package with only the addition of an .info file. I did not see any use of ACS 4.x APIs at all.

I think it is important to improve the SDM to use the APIs that are available with the toolkit. It would be good to at least take advantage fo the acs-workflow package which provides email notifications and assignment of tasks very well.

Collapse
Posted by Don Baccus on
Right, I looked at the aD stuff to and it's not really a port at all.  That's not necessarily bad - ecommerce is similar and people are getting real value out of it - but unlike ecommerce, not only is it not integrated into the OpenACS 4 structure but it's not done ...
Probably I'm talking about hell without speaking to the devil first, but...

Denis and I decided to use OpenACS for our own site. As we rely heavily on Intranet, we will start porting the ACS 3.5 intranet when work has settled a little bit or some big company is willing to spare some if its money with us for doing it. So, nothing will start before May, but we definitly want to drive this ahead AND drive it in the direction Don has been talking.

Don wrote:

Well ... a new SDM tied to a new Intranet-ish suite tied to a knowledge management system would be a very interesting thing.

In other words the old intranet package gave some control over how you can let people (clients) into the system, controlling what they can see and can't see, what they can and can't do, etc. Tie that with the SDM and you'd have something more useful for small consulting companies than bugzilla, I think, due to the nice possibilities that the rich OpenACS 4 datamodel makes possible.

And Malte wrote:

Denis and I decided to use OpenACS for our own site. As we rely heavily on Intranet, we will start porting the ACS 3.5 intranet when work has settled a little bit or some big company is willing to spare some if its money with us for doing it. So, nothing will start before May, but we definitly want to drive this ahead AND drive it in the direction Don has been talking.

It seems to me that dotLRN may provide the base for much of what you're talking about. It has (AFAIK) class and group scoping that could be turned into project and subproject scoping, admin, professor, TA, and student permissions that could be turned into developer, project manager, client, etc., full use of the new portals system, and a nice API that makes it relatively easy to tie new packages into the system. It's got event scheduling, bboard, file-storage, wimpy point, calendar, and other Intranet-like features already set up for it. It seems to me that dotLRN would be the right place to start in terms of building a new Intranet package. I'd love to see both SDM and ticket-tracker integrated with it.

Collapse
Posted by Don Baccus on
Much of what you say is true for the basic toolkit.  What dotLRN brings to the table are specific portlets for the various packages, and as you mention a framework for scoping etc, those these are built on top of the relational segments already present in OpenACS 4.5.

So ... dotLRN provides a working example of how to use them effectively.

dotLRN "applets", which are used to control which packages are mounted to a particular group, would definitely be useful in this context as well as many other contexts, because they give group admins a simple way to add packages to subsites associated with a particular group.

  Group admins don't have to learn how to use the site map tool nor do you have to give them permissions to do so, and the "applets' take charge of tying together packages and portlets.

The dotLRN events package isn't really a scheduler, it just provides a mechanism for defining an event, handles registration, payment, etc.  It's a bit too Sloan-specific to be of much general interest, I think, but we can probably generalize it easily enough afterwards.

I think that the central question for me, at least, is what should SDM and/or ticket-tracker be? I listed a few items that in hindsight may be completely different systems.

For instance, it may very well be that Bug tracking, QA tools and Support tools are totally different beasts. An initial, and incomplete, user-perspective requirement list for each package may be:

  • Bug Tracking
    • Need to list bug
    • Is the bug a security issue?
    • What is the priority of the bug?
    • Who found the bug?
    • Who will fix the bug?
    • Is there a fix for the bug?
    • Once the bug is fixed where does it go?
  • QA
    • Who submitted the piece for QA?
    • Who is testing the piece for QA?
    • What is the problem?
    • Who does it get routed to?
    • What is the hypothesis for the problem?
    • Where does the piece go when the problem is fixed?
  • Support tool
    • Who is accessing the support tool (client or developer)?
    • What is the problem?
    • What is the priority of the problem?
    • Is it a feature or a bug?
    • Is it a helpdesk question or a bug?
    • Who should the problem be routed to?
    • How long did the fix take? (track hours in order to charge client)
    • There should also be a bboard instance for clients to post questions.
When I think of what each of these pieces need, I think they look a lot like what SDM is now. But in practice, I have a sense that there are subtleties in their requirements that aren't really consistent throughout. In fact, I kind of think that QA is much different than Support and Bug tracking, at least from what I've written down.

So whether this stuff is accessed via a portal interface or its own page flow is a very minor question right now. The big deal is, as Don mentioned, whether we can muster the resources to work on this.

IMHO, this kind of software could be huge for the community, as SDM currently is. But SDM's interface is lacking as I don't feel it's terribly user friendly as is. Better than most systems, but as often is the truth, it can be improved alot.

As Malte promised and since this is pretty important for our business if we're going to charge clients for support, I'd be willing to devote developer resources to help a community wide effort.

talli

For those that are interested this had a lot of research put into / mailing lists that may be of use. Not sure of current status but cool non the less and pick up a couple things.
Collapse
Posted by Barry Books on
I started using the 4.X version of SDM a few weeks ago and found lots of little bugs. There are two problems I know of in the following package
  • uses pseudo_contains from ecommerce package. If you don't have it installed you'll need to get it
  • Has hard codes group numbers in various files. (It was that way when I got it). I think you should be a able to have different groups manage different projects and it doesn't seem to support that completely. There needs to be a way of assigning a group of developers to a project.
Here is what I have now SDM
Because of some rather pressing needs Musea has for a couple of client projects, we're going to support the initial development cycle for an SDM in OACS4. Lars will be doing the development before he starts a consulting gig for us, so it's going to be good.

Here's what Lars will be doing initially:

--
I'll aim for something that I can make usable in the real world within 7-10 work days, with a road-map for how it will/could develop over time.

That'll enable me to switch to working on XXX, and it'll enable us to start using it immediately on XXX and other projects, and gain some real-world experience.

I'll spec it out tomorrow, but I don't want to do things quick-and-dirty, meaning I don't want to make something that we'd immediately want to throw out. I do want to do something that can be implemented rapidly, and that we can then incrementally add features to and refactor as we need to.
--

The spec will be posted, of course, and will be developed with feedback. Because the dev cycle will be tight and it's going to be address some of our direct needs (like design cycles, client support, etc), the development might not be totally open. But it will provide a great starting point for continued development.

But if you have ideas for the SDM, please post them now!!! It will really help to have as many ideas in here as possible.

thanks

talli

Collapse
Posted by Tom Jackson on

Talli,

I'm not trying to act too happy about my own software development, but you should take a look at two package I have which will greatly speed up the very boring parts of development. Togeather these two packages handle most all insert update and delete code for acs packages.

The first package is my package-bulider package. I have not converted this to pg yet, but it is available for use by all at: http://multi.zmbh.com:8300/ which allow you to enter your table definition and build both oracle packages and a set of pg functions for insert/update/delete, essentially this creates the pkg.new, pkg.set_attrs, pkg.delete, pkg.reset_attrs and pkg.pkg_p functions for oracle and the correspondingly named functions for pg. For pg, it also creates the package delete script.

The second package called query-writer. This package allows you to create objects which have attributes. For each object you can define function prototypes based on a subset of the attributes. Also, each attribute is protected with respect to the operations that can be performed on it. These protections are grouped (not necessarily an OACS group). Right now I use two groups: admin and default. It is relatively painless to add groups to an object. This is a relatively simplified system: a user is in only one group at a time, and right now only system wide admins are in the admin group, while everyone else is in the default group. However, what this all boils down to is that developers can direct all insert/update and delete operations to one page. This page also takes a return_url variable. During the processing of this page, any number of objects can be worked on. You can insert 2, update 3 and delete 1, of any object defined in the system.

I have been using this package with my merchant-system package, and I have got this thing to elegantly do everything I have needed it to do so far. Another big plus, due to the security groups is that the single query processing page can handle both admin and regular pages.

If the pre-built page is not able to handle a difficult set of requirements, you can use the tcl api which also has several levels of access. This also means that most of your .xql files will only be for regular sql select queries, which self port for the most part.

Please let me know if you want to see the query-writer package in action.

Collapse
Posted by Don Baccus on
It might be nice if the SDM were viewed as an organizer package that uses service contracts to connect to:

1. A ticket tracker
2. A download repository

Getting the design right for this might not be easy in the given timeframe, though. The motivation of course would be to make it possible to drop in alternatives. Especially for the ticket tracker which I don't like all that much. Download's a nice package but I think communication via acs service contract makes sense in general. I think having releases live in the download package is nicer than having them live as tarballs in the SDM as is the case today.

I wouldn't worry much about CVS integration right off unless you need it right off - the existing OpenACS 3 SDM has the pieces but they need some work (speaking as someone who's been off-and-on trying to keep tarballs etc alive here at openacs.org).

Joel Spolsky has a nice write up of bug tracking practice here:

http://www.joelonsoftware.com/articles/fog0000000029.html

Its a good starting point.

Cheers,

Lately I've been playing with BugHost, a bug tracking ASP
(http://www.bughost.com). It's probably a bit more full-featured
than we'd need in ticket-tracker, but it's worth playing with for
ideas. You can get a free 30-day trial of the full service that
downgrades to a permanent free but crippled account at the end
of the trial period.

General Introduction

I think a strong issue tracking system is an important part of the toolkit and a vital part of software engineering. If I don't use a system, issues get forgotten until they cause embarrassment.

Since Lars is going to spend some time on this, I'll spend a minute describing what I like in issue tracking systems based on my experience running multiple projects with multiple clients at Civilution.

The openACS3.2 ticket tracker is pretty good and what I have been using for about 2 years. We made some major modifications to support logging of hours to tickets. If you want to look at how I use it, feel free to email me and I'll let you see some pieces of our system. Its far from ideal though, I haven't been able to do releases well and email notifications are sketchy at best.

I have also spent some time looking at the Fog Creek FogBUGZ tracker, and some other proprietary ticket trackers. As a reference implentation I have very few complaints with FogBUGZ.
http://www.fogcreek.com/FogBUGZ

I find that the workflow for features and defects is similar enough that we have been able to track both very successfully in a ticket tracker. There are some subtle distinctions between them, and its helpful to be able to filter for one or the other. But the general flow is the same.

So onto specific requests:

Major Datamodel Elements

Projects

You should be able to separate tickets and people into distinct projects. At Civilution, we had two projects for each client (one to track billable tickets and one for unbillable tickets, though I wouldn't do that again) and an assortment of internal projects like: Biz Dev, Overhead Tasks, Sysadmin, Codebase.

Its nice if projects have some kind of subdivision like area that you could use to partition a project into documentation, graphic design, and other major ares.

Its nice to have a good sense for versions of projects. We didn't do a very good job of this, but its really nice to notice which version a defect was found in and assign it to be fixed by a certain version. (At some companies if a feature is deferred more than N versions it is dropped where N is typically 2-3)

Users

Users were attached to projects. We only had Administrators and Users, we didn't get any value from the common separation of internal and external users and I wouldn't waste time on it. Everything should be logged and we trusted our clients so it wasn't worth the bother. The 3.2x ticket tracker seems to offer a way to hide comments from the external users, but I don't think this secrecy adds any value to the client relationship so we never used it (except by accident).

Tickets

  • Should always have one person who is responsible for moving it to the next state.
  • Should notify people via email when they become responsible for an issue. Good email notification is probably the single biggest success factor in using the ticket tracker. It encourages people to open tickets if the KNOW that they will be notified of major state changes.
  • Should only be closed by the person who opened it.
  • Should naturally display the history of the ticket. (see FogBUGZ demo for a great example)
Other nice features for tickets:
  • Ability to subscribe to defects and get email notifications of all updates as it moves through the cycles. This is a big wishlist item for me.
  • Attach Files to tickets. Useful files include screenshots, test data that shows the ticket or links to documentation about what it should do.
  • Estimate Tracking: How long will this ticket take to finish from its current state? This is especially helpful for distributing the estimation of a project or figuring out how busy people are.
  • Work tracking: How long did someone spend working on a ticket. At Civilution we modified the intranet and the ticket tracker to do all hour logging through tickets. We then made a new class of ticket call ongoing that never closed (issues like company meetings) and everyone would log hours to those tickets. This worked pretty well.

Hints for using tickets in an org:

  • Make the Severity ratings mean something and only use Severity ratings with meaning. There is no magic bullet for this, you have work out what the levels mean for your organization and think about ways to teach people.
  • As a developer, refuse to work on issues that are not in the ticket tracker. If it can't be fixed while you are on the phone with the client, it should be tracked. The ticket tracker needs to be the canonical place for issues.
  • Give people an easy why to see: Issues assigned to them and issues that they opened. These are my two favorite views for chasing down tickets.
Workflow

The basic workflow is pretty easy:

Someone, lets call him Client Chester, requests a feature or reports a defect. This ticket gets assigned to Project Manager Mary who is responsible for that area.

Mary may fix the ticket, assigned it to Denny Developer to fix, schedule it for a future version (getting it off the immediate plate), request clarification, or decide that its not worth fixing. (FogBUGZ has a pretty elaborate system of Sinks, We just closed tickets and didn't pay to much attention to if they were closed because it was by design or we just weren't going to fix it.)

After a Mary or Denny "fixes" the ticket, it goes back to Chester who is responsible for closing it and being satisfied with how the situation is resolved.

This basic system works great for features too, a someone can request a feature and they have to review that the feature was implemented satisfactorily before they can close the ticket on that feature.

We had a couple of other tweaks here at Civilution. Hot fixes to production servers had a slightly more complicated workflow:

Client would open a ticket.

Dev would fix on dev server.

Client would approve on dev server.

Dev would prop to production.

Client would optionally test on production.

Conclusions

Just to sum up, If you have good email notifications, reasonable ways to divide tickets across projects and across time (with versions or releases), and simple reliable workflow, I will probably be happy.

Thank you Musea for investing some resources in this.

Cheers,

Collapse
Posted by Lars Pind on
Thanks, all, for the feedback, thanks for keeping me busy :)

You've give me so much stuff to look at, all these other implementations, the existing SDM, the data model of which I've looked closer at today, etc., that writing a spec today would've been premature.

Instead, I've given some thought to it, and written up a couple ideas. Please give me your feedback.

Features brainstorm

Features that I've missed at some point:
  • Lookup bug/patch by # (when you find a reference in a CVS comment)
  • "This fix created a new bug" feature: Creates a new bug report, linked to the previous bug report in an obvious way.
  • A separate SDM instance for each major project (so I could say openacs.org/oacs4/sdm/ instead of openacs.org/sdm/, then click "openacs-4".)
  • One single system-wide "my tasks" list (this is part of the future plans of workflow, but it didn't get done)
  • List open and recently fixed bugs for a project: So you can easily check if the problem you're having is one that someone else already knows about
  • "Not a bug" ... but write a work-around, so that other people who also think that this is a bug, can learn what to do.
  • Answer questions like "What happens to my bug after I submit it? Who's this assigned to? What's happened so far?" Track when it's been read (the first time) by the assignee, when it's re-assigned, etc.

Scenarios

  • "I think I've found a bug, I want to check and report"-check open and recently fixed bugs to see if the problem has already been submitted or even fixed, possibly find a workaround, or otherwise submit a new bug report.
  • "I'm the maintainer of this module; show me what's going on": New bugs/features, new comments/discussions on bugs, re-opened bugs, etc. Lets him triage bugs, adjust priority/severity, defer, estimate time to fix, etc.
  • "It's time for me to go to squash some bugs, show me the most important ones to work on in my module, or across all modules"
  • "I posted a couple bugs, or I'm interested in some bugs, what's the status on those?"
  • "I'm the manager of this project, show me whom of my people to humiliate in public"
Other scenarios? This is probably the most important thing we can talk about: What are people coming to the bug-tracker for? What is their goal? What's your goals when you're coming to it in different situations?

Notifications obviously throughout on bugs you're interested in. You can be interested in bugs on a bug-level, module-level, package-level. You're automatically deemed interested in bugs that you've submitted, or in modules that you own.

Random Thoughts

  • Releases: Releases aren't working for us in the SDM today: People aren't diligent about setting the right release when they submit or fix a bug. If you go look at release 4.5.0b1 (https://openacs.org/sdm/one-package-release.tcl?package_id=9&release_id=52) you'll see that there is only one known bug and no fixed bugs. Which is wrong. All the known bugs are against the prior release, but they haven't been fixed, so they should be shown here, too. The missing fixes is another problem, though, which is that all the bug fixes have had release 4.2.0 assigned to them. That this could happen, that it isn't more clear what's going on is a bug in the system. The result is that the data aren't trustworthy.

    What should be done? Bug should probably be implicitly inherited from one release to the next—if it wasn't fixed, it's probably still there. I think that maybe we're using releases on a too fine-grained level? Potentially every single nightly tarball could be deemed a "release", but it's not. Maybe releases should simply be major releases? Or it could be smart about major/minor releases somehow (so that you can release a bug-fix-release to an old release while you're still hacking away on a newer release, i.e. branches).

  • I want to be able to say openacs.org/oacs4/sdm/acs-admin/ to go straight to that module. Or we could say /sdm/oacs4/acs-admin, I'm not sure which is better. Either would work. In the first, /oacs4/ is assumed to be the home page for the OpenACS 4 project.
  • Is there any reason to limit to one "module" level below the "package" level? Just go as deep as you like, and things should work as expected. On the other hand, is there any reason to make it a tree? Tell me what you think.
  • ACS-Workflow: Even though I'm the author of ACS Workflow, I'd decide against using it here. I'll think about ways that we can integrate it in the future, but right now, the UI of Workflow isn't there. Integration with packages like this is too cumbersome and unhappy. We need to solve this problem, obviously, and I'm looking forward to getting a chance to do so, but we don't have time now.
Hey Lars,

Here's another scenario:

I'm in charge of verifying that bugs marked as "fixed" are, in fact,
fixed before they're closed out.

And a random thought:

One of the things I like about bughost.com is that it's pretty
configurable. Here are some things I can configure:

- I can define my own roles

- I can set priviliges (view, read, and write) on pretty much every
field.

- I can also set fields as required or optional (with contingincies
in case the person viewing does not have write privileges) and
set defaults on some fields.

- For fields like "severity" and "when this will be fixed," I can
define the choices in the pull-down menu.

In my book, having flexibility, i.e. --the ability to shut a field off or
change the range of choices-- is often more important than
having a huge number of fields. The system should allow you to
make your workflow as streamlined and simple as possible
given the needs of a particular team/project.

Collapse
Posted by Don Baccus on
The release machanism per se is OK currently, I think, in that a package creator has to explicitly name a release and upload the release file (which, as I mentioned above, I'd rather see stored in the download repository so all downloads reside in one place, with links from the SDM for managed code, of course).

But Lars makes a good point that there's poor integration between releases and bugs.

This is always a troublesome thing - we should default to the latest version, of course, but folks don't always use the latest version and can't always test against the latest version.  Which adds to maintenance overhead, unfortunately, and makes errors in data entry probably unavoidable.

When bugs are fixed they should be marked as fixed in the "next" release no matter which release they've been reported against, though.  I say that because I don't forsee us trying to maintain past releases  but will manage the project by moving forward and fixing bugs in for the next release.  People can download patches to patch their existing systems of course (a good reason to require patches be filed for bug fixes, actually, if you think about it!).

So essentially all bugs fixed after release "(i.j.k)" can be marked as fixed in release "(i,j,k)++" in our linear release scheme, at least.

We can make this the default anyway ...

As far as workflow goes ... I've done some work integrating workflow into a "normal" package UI and have workflow panels that work both from within a package and from within the workflow UI (template "include" is your friend).

So it is possible to use workflow and to have a decent UI - if you don't depend on the built-in workflow UI for tasks, that is.

As Luke mentions,  the workflow UI ain't really quite there yet in terms of user-friendliness, but if you let your users work through steps naturally within the package framework that's not really an issue.

I do want an improved workflow UI - I like the idea of a user being able to approach all their tasks from a nice, well-designed central workspace.  I also like being able to dip into a package and do my work that way, and workflow allows that to be done seamlessly if you work a little workflow panel magic.

Workflow's not integrated with permissions while the rest of the toolkit generally uses permissions to decide "who can do what", in my mind that's another practical problem that needs solving.

I've got some other notions about workflow, too, that have grown from my use of it.

So ... I wouldn't recommend against workflow though I agree with Luke's assessment of the parts of the package UI.

Collapse
Posted by Don Baccus on
I meant "Lars" not "Luke" above ... oops!  Sorry, Lars ...
My biggest feature request for any sort of ticket tracker/intranet
sort of thing is something not really suited to the web, but I think
it could be done:  a time tracker.  You know, an electronic
stopwatch.

My problem is this:  if I don't use one of these time tracking thing-
a-ma-bobs I don't ever get my time recorded (and even with one,
remembering to use it is a bit hit or miss).  So I have my file for
each project and my times tracked (on good days) for each task.
Cool.  But now if I want to have that time recorded in the ticket I
have to go look it up and enter it, possibly adding up multiple
times if it got split over several sessions.  Most of the time this
just ain't gonna get done.

A much better (for me) solution would be to have buttons right on
the "one ticket" page to start, stop and pause the clock.  Or even
a page where multiple tickets could be being tracked at once.
doing this should be really easy with a database behind the
scenes;  just save the stop and start times and compute the
difference.  Then, of course, granularity needs to be
configurable.

To make this really useful I'd also want a special kind of ticket
which wasn't a bug or a feature request, but more like a task list.
Then I could create one of these "todo" tickets for each of my
development tasks, just as I currently create line items in my
ticket tracker, and have everythigng tracked this way.  And I'd
want the ability to do time reports by project, of course. :)

My $0.02,

Janine,

Thats almost exactly how we used our ticket tracker and we talked about implementing the stopwatch interface but never quite got around to it. Having played with punchclock on my Palm for a bit, I think that the UI for doing that kind of time tracking would be pretty straight forward.

One implementation is to add an [out] button by each bug/issue/feature/dev task in the open issues list. Clicking it, starts running the clock on that feature. (In punchclock the line turns bold and the button turns to [IN]. We just had a log hours button by each ticket.

Cheers,

Regarding the stopwatch thingamabob, I wonder if this might not
be a good application for Jabber. You issue your start, pause,
resume, and stop commands through your desktop jabber
client, which sends the SOAP-encoded message, along with a
time stamp, to ticket-tracker.

Just a thought.

I haven't used jabber yet so I might be missing some huge benefit.  What does doing that with jabber add over just giving the user a button to press, which causes the current time on the server to be stuffed into the database?
Janine, there are two benefits to thinking about Jabber in this situation. First, for people who have unreliable or slow connections, it may help to do the time stamp on the client side. My upstate connection, for example, can hang for minutes at a time, and if I'm not paying attention it will sit like that indefinitely sometimes. I wouldn't want to depend on that for logging my time.

Secondarily, with the right conduits you could log task starts, stops, etc., using your pager, your PDA, etc., which I would imagine might be nice for some.

Depends what the tool is for.  If you ever intend to use it as a regular time
clock you either must trust the end users or use the server side time.
Collapse
Posted by Lars Pind on
Does anyone know where I can find the source code for the latest (live) version of the SDM?
Collapse
Posted by Tom Jackson on

The problem with Jabber is that you have to program both the clients and the component side to get this idea to work. Most clients come with only a very simple interface and it isn't dynamically expandable like a web page. There is no simple thing like an encoded url you can choose. I experimented in using the 'thread' tag of the message namespace to hold a url, and it works fairly well, but this does not provide anything to choose, the user still has to type in some text response. Jabber should be more useful for machine to machine for this kind of thing. So my assessment is that Jabber would have a disadvantage in that programming has to be done on both ends.

You definitely wouldn't want to customize the Jabber client; that would defeat the purpose of having multiple conduits to different devices.

What you *could* do, however, is use Jabber as a very simple (English-like) command line interface for different components. Imagine, for example, having a connection open in Jabber to your ticket-tracker instance. You could ask it to "List commands," and it would give you a list of the various things you can tell it to do via IM. One of those things might be "List my tickets." Once you get a list of your tickets, you might tell it to "Start timing foo." Later, you could tell it to "Pause timing foo" or "Resume timing foo."

Obviously, you wouldn't want to get too carried away with this, but you could develop a very simple interface to do crucial tasks you want to accomplish when you either don't have access to a full browser or you want to time-stamp something over an unreliable connection. You could do all kinds of things with this. For example, you could restart a hung server using your two-way pager.

An added benefit to this is that, by having IM connections open to a bunch of packages at once, you'd have quick and easy access to issue commands to any or all of them. It wouldn't replace the web interface, but I could imagine situations in which this sort of interface would be handy and convenient.

Hmm.  Well, I know I can be a Luddite at times but this sounds to me like something that sounds good in the marketing slicks but is a bit less glorious in practice.  If nothing else, most of those wireless devices are even more unreliable than most developer's net connections; I have e-mail delivered to my cell phone (a pager substitute) and it can arrive anywhere from immediately to hours later.  So one would have the same problem of not knowing for sure that the command was properly received;  you'd still have to wait for the response to be sure.

I'm not saying this shouldn't be done; this sort of feature goes over well in presentations even if no-on ends up using it.  But if anyone is actually taking notes here, I'll put in my vote for having simple buttons for those of us with good web connections, along with whatever more spiffy solution you choose.

Collapse
Posted by Lars Pind on
Okay, I'm still not done with the functional spec, but I figured I'd post what's there now, so you can all take a look and give me your feedback: http://pinds.com/tmp/bugtracker-specification. I'll continue hacking on it tomorrow.
Collapse
Posted by Tom Jackson on

Michael & Janine,

Jabber can be used as Michael suggests, the apm package I wrote shows examples of this type of use. However, I would agree with Janine in that it is quite a hack, and very ugly. Why would someone choose to operate by typing in commands instead of clicking on a link or button, assuming both were available? Maybe the point is that you cannot click on a mobile device? I don't know about that. As a protocol, Jabber is not more reliable than HTTP, but rather less. If you need reliability for disconnection, email would be the best, since it was designed for intermediate storage of messages. Jabber will store messages at the receiver end, but that is probably where the component is located anyway.

Lars

Your summary looks great, any word on the data model to support this?

Collapse
Posted by Lars Pind on
I have some data model sketches at http://pinds.com/tmp/bug-tracker-outline.sql, but otherwise it's still mostly in my head.

Any experts in acs-relationships and all that crud out there who can help me with some of the details on that? It would seem to me that that would be the right way to model relationship between bugs (duplicate, depends on/blocks, just related, ...), user interest/"notify me", mapping tickets with patches, assignments, maybe even mapping bt_code_values to bt_tickets.

Any comments on that assumption? Is that the right way? Will it perform? Will it be more trouble than it's worth? Any implementation hints?

ACS Rels seems like the right tool for the job. The advantages:
  • easier to tap into for other packages who want to talk to BT
  • no real query overhead for simple rel-types. Though you should probably subtype acs_rels to add semantic value to the relationship type, there is no need for your subtype's table to have any new columns, and even less need to join against it. Of course if your new rel-types carry attributes, and you subtype your subtypes, you can get a bunch of joins pretty quick.
The disadvantages:
  • Object instantiation/deletion overhead if you have to do a lot of them
  • Ups the object count. I'm hoping this is pretty much not a problem anymore.
For what you describe, acs-rels seem like the right thing to do with one exception. I would side with the part of you that suggested using perms instead of acs-rels to define a replacement for the module_users table. The downside for the perms approach would be that if a large number of modules existed within a project, you'd be hitting the db pretty hard on the permissions check for the module list page. I haven't got a good feel for how slow that could make things on the latest OACS, but the flexibility and standard-ness of using perms like that would be an worth it, if it doesn't hurt too bad under real world conditions.
Collapse
Posted by Lars Pind on
John and others,

What is "sdm_module_users" actually used for? Do you have to be a "user" of a module to be able to submit bugs in the module? Or to be assigned bugs to?

If the latter, does someone who's a global bug fixer guru have to be registered as a user of every single module?

I'm probably missing something lame here.

The comments in the 3.x sql file led me to believe that it was to decide if a user could even see a module in the listing.  I think it was a simple answer to the question "What if we write mostly open source software, but we have a couple of modules that we need to keep under wraps?"... not intended to scale to more than a few special people who maintain the module code.  ACS Perms would allow some much more complicated scenarios.