Forum OpenACS Q&A: Talli the Provisional Bug Czar

Collapse
Posted by Talli Somekh on
I am Talli the Provisional Bug Czar, son of Zingtoot the Assigner and brother of Hootinee the Resolver.

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.

talli

Collapse
Posted by Dave Bauer on
Hmmm,

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.

Collapse
Posted by Jun Yamog on
*shivers*  cczzaarr.... arre you... related... to... to... the self.... proclaimed... looooossserrr... at NY?
Collapse
Posted by Lars Pind on
Talli,

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.

/Lars

Collapse
Posted by Talli Somekh on
OK, so we need to upgrade ASAP. I know Dave and Steve Ivy are looking into that. We'll have to start working on a strategy soon...

talli

Collapse
Posted by Dave Bauer on
Lars,

Hi.

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.

Collapse
Posted by Talli Somekh on
Dave, excellent!

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.

talli

Collapse
Posted by Lars Pind on
Hi Dave

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.

/Lars

Collapse
Posted by Lars Pind on
Wait, turns out I did take notes, and I even sent it by email to you back then. Just re-sent it.

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.

/Lars

Collapse
Posted by Frank N. on
Dave,

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.

Frank.

Collapse
Posted by Dave Bauer on
Thanks Frank, I'll check which 7.3.x its on. I think its 7.3.2. Anyway this is just the test system to make sure we _can_ upgrade.

Lars,

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.

Collapse
Posted by xx xx on
Talli, package maintainers are scarce.
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.
Collapse
13: 3 month release cycle (response to 9)
Posted by Andrew Piskorski on
An OpenACS point release every 3 months sounds very, very good to me. The exact best time period could be debated I suppose, e.g. every 4 months is probably just as good as 3, if those 3 or 4 or whatever month release targets are actually hit reliably.

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...