Forum OpenACS Development: Package maintenance & lingering bugs

Posted by Jeroen van Dongen on 10/03/04 12:51 PM

Gents & ladies,

While summarizing the dev forum last friday, I noticed that there are quite a number of old, unresolved bugs in bugtracker. Also, Jades excellent new packagelist (https://openacs.org/projects/openacs/packages/ - should be linked from the frontpage BTW) shows a blatant lack of packagemaintainers. Somehow I feel those two issues are related.

In order to achieve a higher quality standard then we already have I would propose the following.

* Every package needs a maintainer to be fully supported as part of OACS
* Orphan packages are clearly labelled as such (perhaps we should split Jade's list in two) and you cannot file bugs against orphan packages. Unless you're willing to become the maintainer.

Perhaps we can even go as far as not including orphaned packages in the releases. If you really need the package - become the maintainer. After all, a free lunch does not exist.

To lower the hurdle to become a pkg maintainer we should clearly define what it means, and put not too much weight on them.

A pkg maintainer does imo not have to write all (or perhaps even any) code himself or fix each and every bug. I figure someone in this role as more of a gatekeeper, with basically three tasks:

* keeping track of the developments wrt to package and making sure that any drastic changes have the necessary support from the community

* keep a close eye on the buglist of the package, in relation to this we should perhaps set more strict guidelines for bug classification (a critical/urgent bug cannot be open for 8 months, without getting attention, and still be urgent. It's either already resolved, or not really urgent)

* make sure the package gets tagged in time for new releases.

To get an idea wrt to the lingering bugs I mentioned, the following is a list of CRITICAL bugs open for 1mo or longer (12 of which are even prioritized as URGENT).

ACS Authentication, #844 - Lars Pind
ACS Kernel, #1761 - Don Baccus
Webmail, #1415 - unmaintained, bug reported by Joel Aufrecht
Chat, #1442 - unmaintained, bug reported by Joel Aufrecht
Jabber, #1443 - unmaintained, bug reported by Joel Aufrecht
Mailing list manager, #1444 - unmaintained, bug reported by Joel Aufrecht
Classified ads, #1581 - unmaintained, bug reported by Ben Koot
Photo album, #1599 - unmaintaind, bug reported by Hazi Gharagozlou
Edit This page, #1601 - unmaintained bug reported by Hazi Gharagozlou
ACS LDAP, #1632 - unmaintained & deprecated, bug reported by Matthias Bauch
Bugtracker, #1748 - Lars Pind, assigned to Joel Aufrecht
Forums, #1843 - unmaintained, bug reported by Deirdre Kane
2-dotLRN general, #1878 - ??, bug reported by Mohan Pakkurti
Openacs general, #1881 - ??, bug reported by Samer Abukhait
Logger, #1885 - unmaintained, bug reported by Richard Hamilton assigned to Peter Marklund
dotLRN syllabus, #1965 - ??, bug reported by Deirdre Kane
IMS Enterprise, #2020 - not in maintainer list, bug by Jeff Davis
ACS language, #2027 - Peter Marklund
File Storage, #2082 - Jeroen van Dongen, as of recently -currently still assigned to Don, (Don, if you re-assign it, I'll fix it & close the bug.)

Rgds,
Jeroen

2: Re: Package maintenance & lingering bugs (response to 1)

Posted by Jade Rubick on 10/04/04 01:51 AM

Jeroen: this is a really important topic, thank you for bringing it up.

I should note that the project page that I've set up isn't completely done yet. The packages that have "Description" in the description column have not been updated yet.

I agree that we need package ownership or gatekeepers, and I'd love to see some attempts to define these roles. Perhaps there could be three tiers of package developers, depending on how much time or effort people are willing to put into the package.

My reason for putting together the project page was motivated by the same frustration: it seems confusing who is responsible for what (and how to become a contributing part of the community), and I haven't seen much activity from the OCT recently. Perhaps they are busy with client work? That's good in a way, but I've been wondering what's up.

I'd also like to see us develop statistics on OpenACS that we can use to measure the growth of OpenACS. Are we attracting and keeping developers? And perhaps more importantly, are we attracting and keeping administrators who install our software but don't program them? My take is that we are very slooooooooooooooooooowly growing, but that's really not going to cut it if we want to keep OpenACS as a vibrant platform.

5: Re: Package maintenance &amp; lingering bugs (response to 2)

Posted by Malte Sussdorff on 10/04/04 07:05 PM

What do you think about putting the following processes in place:

- Update the documentation automatically in a central place. It shall only be necessary to edit the documentation XML file of the stable release and get the documentation generated in HTML and committed to CVS. Someone keen on writing a BASH script to do this ?

- The release begins by updating openacs.org to that release. Once this is done publish the release. But maybe Joel can post the steps necessary to cut the release (once the branch is deemed release worthy).

This way we find more bugs that annoy us and fix them as all of us are using openacs.org. And the documentation is easier to maintain, thereby making it more likely for people to maintain it in the first place.

7: Re: Package maintenance &amp;amp; lingering bugs (response to 5)

Posted by Jade Rubick on 10/04/04 07:31 PM

Malte: these are great ideas, I think.

Of course, the work doesn't happen automatically. We need volunteers to do the openacs.org upgrade testing. It can't all fall on Joel's shoulders.

I asked Jeff about generating the documentation automatically. He said there are often errors that need human intervention, but perhaps that could be part of the script: send an email to the doc group saying: "hey, something went wrong, better take a look at it".

3: Re: Package maintenance & lingering bugs (response to 1)

Posted by Jade Rubick on 10/04/04 01:53 AM

I'd also like to encourage people to take on just a couple minutes of day towards the overall community. Those with commit access, go through old bugs for a few minutes a day, for example. If you are installing OpenACS, submit updates to the documentation. Etc.. OpenACS is a commons, and unless it is treated respectfully, we end up with a tragedy of the commons, where everyone takes but nobody gives.

4: Re: Package maintenance & lingering bugs (response to 1)

Posted by C. R. Oldham on 10/04/04 04:29 PM

and you cannot file bugs against orphan packages. Unless you're willing to become the maintainer.

I respectfully disagree here. A newbie to the community needs to be able to see how bad a state an orphaned packages is in. Clearly marking the package as orphan should be sufficient.

6: Re: Package maintenance & lingering bugs (response to 4)

Posted by Jeroen van Dongen on 10/04/04 07:33 PM

RE: C.R. Oldham

I respectfully disagree here.

You're most welcome, but I'm a little confused as to what you disagree with.

A newbie to the community needs to be able to see how bad a state an orphaned packages is in.

No disagreement there ...

Clearly marking the package as orphan should be sufficient.

And none here either ... the first part of the sentence you quoted was "Orphan packages are clearly labelled as such (perhaps we should split Jade's list in two)"

AFAICT being labeled as "orphaned" should say it all. An orphan package is in an unknown state and perhaps does not even work as advertised. So to a newbie the message wrt to orphan packages should be "don't touch it, unless you're in for a challenge".

8: Re: Package maintenance &amp; lingering bugs (response to 6)

Posted by C. R. Oldham on 10/06/04 04:57 PM

Sorry, I must not have been clear in my original reply--I meant that I think you should still be able to file bugs on orphaned packages.

9: Re: Package maintenance & lingering bugs (response to 1)

Posted by Andrew Piskorski on 10/10/04 09:29 AM

Why is anyone even discussing not allowing people to file bugs against so called "orphan" packages? That's insane. If there is a bug, any bug, we want to encourage people to file it in the Bug Tracker, always!

10: Re: Package maintenance & lingering bugs (response to 1)

Posted by Jeroen van Dongen on 10/10/04 10:31 AM

Ok - then let me ask you: what's the point of having a bugtracker full of bugs that are not going to be resolved?

I agree that we want people to file bugs - but they only do so when there is a chance the bug gets fixed (or at least a conclusive decision is made as to what to do with the bug) within a reasonable amount of time. Otherwise they file a bug, only to never do it again.

It's a balancing act between quality and quantity - and my opinion is that we're on the way to let the scale tip over in the direction of quantity. And that's my main point. Let put more focus on quality and less on quantity.

Therefor I essentially propose an explicit three-level system of:
1) oacs the toolkit
2) maintained packages
3) unmaintained packages
as opposed to the current two-level system (toolkit/pkgs)

If we allow filing bugs for level 3 it's fine with me - as long as we make painstakingly clear that one should not have the expectation of anything happening soon - unless they do it themselves.

But I'd rather see that we disallow it and use it as an incentive to get people to become pkg maintainer. If there's currently no maintainer, apperently nobody cared enough for the pkg. If you care for it ...

11: Re: Package maintenance & lingering bugs (response to 1)

Posted by Torben Brosten on 10/10/04 12:15 PM

How does willfully perpetuating a state of ignorance about the number of bugs in the system help us?

Quality and quantity? Fewer bug reports doesn't mean more quality. It means less quality sooner and longer.

Don't let the number of bugs discourage you. It's a passing phase, due to the tremendous amount of work in progress right now: .lrn being refactored into openacs etc. It's natural for the number of bugs reported to increase for a time. The key is to prioritize them, and provide an easy means to have as many developers as possible quash them.