A proposal for a bug-shooting strategy

A proposal for a bug-shooting strategy

by Przemyslaw Stencel -
Number of replies: 5
I've just experienced the kind of support that Dr Strauss believes can only be received in the case of commer$ial platform$. I found a bug in the assignment module, filed it in the bug tracker in the evening and got the fix for it the next morning. big grin Edit: Actually, it's not the kind of support you can expect from a commercial vendor - try that with Blackboard or WebCT!

Sorry, I just couldn't resist telling you all how happy I am that I am using one of those unreliable systems created by a smattering of teenagers too young to work at Redmond, hackers, virus creators, and a menagerie of others, a platform which cannot possibly offer the same level of support as the professionally built product which sports excellent "project planning, quality control, coding standards, accountability, version control, and support". wink I did use WebCT for a few years and never had my bugs fixed so fast. And as far as the feature requests are concerned, my feeling was that they were all automatically deleted on the server before anyone even read them. Now, compare it to this community!

However, I think there are a few things that we can learn from the WebCT guys. One such thing might be issuing hot-fixes. In the example of the bug I filed it was fixed in CVS (Moodle 1.2 dev) in a few hours, but I had to fix it myself in my 1.1.1 installation. It was not difficult (just replacing one file), took me just a few minutes, but I guess there are a lot of Moodle 1.1.0-1 users who will continue running their moodles with the faulty assignment until they also run into this bug and then they will have to search the forums or the bug tracker to solve again the problem which has long been solved.

I'd like to suggest an additional resource with such hot-fixes. Whenever a bug is fixed which does not only relate to the new features in the dev version, but also exists in the stable version of moodle, a hotfix could be published. It doesn't have to be a whole new installation package (e.g. 1.1.1, 1.1.2, etc), but just the one file or a few files that need to be replaced.

What do you guys think about it?

Cheers,
Przemek
Average of ratings: -
In reply to Przemyslaw Stencel

Re: A proposal for a bug-shooting strategy

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
I completely agree that a stable branch and a development branch running in parallel would be a great way to go.  Lots of mature projects do this.

In the past it hasn't been necessary for Moodle, since major releases were very close together (1.0 --> 1.0.6 took two months!), but as Moodle gets bigger and there are more users the releases are slowing down to several big ones per year.  Putting together releases is actually heaps of work ... there are a lot of things that need to come together.  Splitting into maintaining two streams right now can't work, given the available manpower, all it would do is stunt development on 1.2.

What I've been aiming for is for 1.2 to have a good set of basic functionality that is more or less "feature frozen" at that point as a stable version and continues only with bug fixes.  I would be really happy if someone would completely take over the management of that in CVS, and keeping a steady series of 1.2.x releases coming out with bug fixes and a minimum of feature development..

Moodle 2 will branch from this development as a separate project, and there will be a series of major structural changes in it based on lessons learned from version 1.  Upgradeability from 1.x to 2.x is a major goal, but it will have to be secondary to the new functionalities (templates, classes etc), because this is a forward-looking version.

Later on with 2.1, 2.2 etc, I would hope it would be possible to delegate branch managers for each version to maintain and back-port fixes as necessary.  These would either be volunteers or moodle.com employees wink
In reply to Martin Dougiamas

Re: A proposal for a bug-shooting strategy

by Ger Tielemans -

A side effect of the bugtracker is that people say (I herad this during a public presentation...): Look on this screen MOODLE IS FULL OF BUGS,their are now mire then 900 bugs...

  • bugtracker is a mix of real bugs, OOPS-my-mistake-faults (like I did by mixing up two versins in CVS), and wishes (should not be in a buglist or changew te name)...
  • How does bugtracker present the average solving time for a real new bug?
In reply to Ger Tielemans

Re: A proposal for a bug-shooting strategy

by Marilyn Fleming -

I've seen another place that has something similar, but calls it "issue tracker" instead of  "bug tracker".

Maybe it would help if you didn't cite the 900, but broke it down as "feature request", "stable release issues", and "development release issues".  Anybody who thinks a development release should be bug-free is an idiot! Also, you might distinguish between outstanding issues and resolved issues.

I am new to Moodle, and I think the way releases are handled is great. First, there's a way to get the development release without going to CVS (something I can't do). The code is beautifully organized, so I can actually tell what's going on. The documentation talks about how to install an upgrade. Even if you don't back up before putting an upgrade in, Moodle does a pretty credible job of backing you out when you re-install the stable release. I also like the way bug tracker lists the 10 most recent reported and resolved bugs.

In reply to Ger Tielemans

Re: A proposal for a bug-shooting strategy

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
The whole bug tracker is horrible .. I want to replace it with a Moodle module called "tracker" that integrates with these forums.  It's just a matter of finding time.
In reply to Przemyslaw Stencel

Re: A proposal for a bug-shooting strategy

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
In the short term, if someone wants to package up a 1.1.2 that just contains important bug fixes since then, please let me know!