Forum OpenACS Q&A: Talli the Provisional Bug Czar
I have arrived to clear out the massive numbers of open and unassigned bugs that sit in the OpenACS bug tracker.
The first step I will be taking is to assign the 296 unassigned bugs to someone. If a bug if is related to a package that has a maintainer, the bug will be assigned to him. If it does not, the bug will be assigned to an OCT member who's responsibility will be to track the bug or to delegate the assignment to someone else.
I will also be spending time sending out emails to people reminding them of their responsibilities to close bugs that have been resolved. I spent time closing some 80+ resolved bugs that have been sitting in the tracker for 3+ months (some were there for 2 months and I closed them because they were non-critical, I trusted the resolver or the resolver was the submitter). I also emailed others who submitted bugs that were resolved to come and close them. So we're now down to 3 resolved, unclosed bugs!
I'll post more as thoughts come up.
I think what needs to happen is that bugtracker should, whether someone subscribes or not, is email the submitter to let them know to come back and close a bug. I don't think it works this way now.
Also we need to assign package maintainers to all the packages, and auto-assign the bugs to them. I can't imagine any reason that this would be a bad idea, unless someone wants to examine every bug and assign them manually.
I also think automatic reminders are a good idea. Something like a weekly summary of open bugs sent to the package maintainer. This probably requires the changes to notifications I suggested.
Thanks for taking up this role.
In terms of bug-tracker improvements, the first thing that needs to happen is that openacs.org needs to be upgraded. There have been a number of improvements since the last upgrade, which was a looong time ago.
So adding these features to OpenACS isn't going to get us anywhere until openacs.org gets upgraded.
We should upgrade to 5.0 as soon as that release is out.
If we want to minimize the pain of upgrading then, we should upgrade to a clean 4.6.3 today.
I am in the process of upgrading the site. There are some issues running the data-model upgrade scripts from the old version openacs.org is running on postgresql 7.3. I finally tracked down the problems with acs-kernel by upgrading on postgresql 7.2 before dumping the data.
Bugtracker is also taking a little effort along with ETP. I haven't even looked at forums yet :)
Upgrading the site is in the works, I will provide an update soon.
We should probably also consider adding a section to the homepage where the latest bugs are published as well. I fear that the bug tracker is being neglected because it's not obvious enough. If we have it on the homepage, perhaps users who visit will be more aware of it.
Back when we wrote workflow and bug-tracker at the beginning of this year, we actually ran the upgrade scripts on a clone of openacs.org, so they should work fine.
The tricky part was upgrading acs-kernel and all the other packages, since they've been manually patched from time to time, so the version numbers in the APM are out of sync with reality.
Basically what I did was upgrade one package at a time, doing a db-dump after each successful step, and restoring after each failed step, and eventually I got through.
Hard work, though. I wish I'd taken notes of which packages caused problems and which didn't.
If you run into problems with any of the packages we've written, please do get in touch, so we can help sort it out.
Things may have changed since then, though.
Good luck! :)
In the future, it would be good if we could keep openacs.org much closer to a stock install, and get better at bringing enhancements from openacs.org back into the code base.
I'm starting to nurture an idea of having a fixed 3-month release cycle, so we'd have a new release every quarter, and then simply cut scope for each release in order to make the schedule a reality. That would make it much more feasible for everybody to keep in sync, because they would have to wait at most 3 months for a new feature to come out as part of an official release.
We'll try to gain some experiences during the 5.0.0 release cycle, then we should have a discussion and a TIP about the release process going forward. Just loose thoughts so far.
You may be aware of this, but just wanted to note that PG 7.3.4 is out, and people are strongly recommended to upgrade if running 7.3.
Exactly. During this process I am merging openacs.org with openacs 4.6.3. I have created a openacs-org branch of the OpenACS repository. So it should be _relatively_ simple to update to 5.0, then merge in the customizations.
Some day, I think it would be appropriate to require the upgrading OpenACS.org be a step in the release process. Part, eat your own dog food, part testing. Another idea I had was to nightly install a checkout on a demo server, or at least at regular intervals.
Wouldn't it be a good idea to email all 'bug submitters' first -after the 5.0 alpha release is out- and ask them to verify if the bug is still present (on a testserver if possible). Hopefully it will turn out that many of the bugs have been resolved already.
Unfortunately, releasing anything isn't quite as simple as just cutting scope until the deadline is met, there's real work that needs to be done in order to make sure both that the code is ready for release, and that the grunt work of the release process itself gets done.
But I think it's a really, really good idea to try...