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

Collapse
19: Response to Software Development (Bugs, QA, etc) and OACS (response to 1)
Posted by Lars Pind on 03/14/02 10:08 PM
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.