Development process issues [LWN.net]

Development process issues

Posted May 2, 2011 18:37 UTC (Mon) by tchernobog (guest, #73595)
Parent article: New features in PostgreSQL 9.1

The biggest problem the project struggles with is the constant torrent of patches and feature ideas being submitted, which has been growing at a much faster rate than the pool of reviewers and committers has.

I know they are really used to it, but having a public bug-tracker would make development *much* easier in my opinion. Handling bugs in mailing lists always looked like a... er... "strange" idea to me. Dependencies, severity and history tracking, not to mention things like automatic commit monitoring and closing of bugs (for example, Redmine does it) are things that are not easy to do with plain-text e-mails. Also, everyone subscribed to MLs receive the whole corpus of all bugs, and searching for dupes is fairly harder.

(Log in to post comments)

Development process issues

Posted May 2, 2011 21:41 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

While I don't disagree with the notion that a "real" bugtracker might be useful I doubt that it would solve the current shortage of experienced developer's time.

Development process issues

Posted May 3, 2011 1:20 UTC (Tue) by jberkus (subscriber, #55561) [Link]

There are other reasons why having a public bugtracker would be a good idea. Speeding up reviewing is definitely not one of them though. New features are not bugs, and vice-versa.

We *do* have a web tool for reviewing: http://commitfest.postgresql.org

FWIW, the bugtracker thing is a longstanding PostgreSQL project issue. Unfortunately, half the contributors don't want one, and the other half can't agree on which bugtracker to use. We'll get one eventually, it's just not going to be soon.

Development process issues

Posted May 17, 2011 21:01 UTC (Tue) by oak (subscriber, #2786) [Link]

> New features are not bugs, and vice-versa.

That's semantics. One person's bug is another person's feature, and vice-versa. Also, fixing bugs properly sometimes requires implementing new features.

Btw. AFAIK Mozilla uses Bugzilla for tracking features / roadmaps and Bugzilla has extension(s) for task time estimation & tracking if one wants to add some project management on top of it...

Development process issues

Posted May 4, 2011 16:10 UTC (Wed) by josh (subscriber, #17465) [Link]

The Git project doesn't use a bug tracker either, and they claim it as a feature. To summarize their opinions:

Benefit of a bug tracker: bugs and feature requests don't get lost when people stop working on them. Downside of a bug tracker: bugs and feature requests don't get lost when people stop working on them.

Bug trackers do incur a certain management overhead, and bugs can rot in a bug tracker if that management doesn't occur.

Development process issues

Posted May 5, 2011 4:16 UTC (Thu) by pabs (subscriber, #43278) [Link]

I think the usefulness of a bug tracker really depends on how active a project is. For Linux, Git and PostgreSQL they are less useful than in that random game that got abandoned a number of years ago that you want to revive. In the latter situation a pre-existing roadmap (bug list) can be useful.

Development process issues

Posted May 6, 2011 16:00 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

There's another benefit to a bug tracker: it relieves some of the need for developers to work on the bug at all.

When I report bugs in bug trackers, even with fixes, I rarely expect to see a fix in the distribution. I just want my work to be available to other users so they don't have to duplicate it. Users can see "it's not just me, the code/documentation is broken" and find workarounds and patches to fix it locally.

In fact, often the bug I reported is already in the database, but by using different words to describe it, I make it easier for the next user not to miss it.

In a project where developers keep up with bug reports (and actually respond rather than just dismissing them), a bug tracker is probably a net loss to the community compared to email.