[Mageia-discuss] Think about bugzilla monitoring?

[Michael Scherer]

Le samedi 25 septembre 2010 à 07:57 +0300, Ahmad Samir a écrit :
> On 24 September 2010 14:58, Juergen Harms <Juergen.Harms at unige.ch> wrote:
> > Picking up from where Mageia forked off, many things activities look like
> > continuity from Mandriva Linux. But forking is also a challenge to find not
> > too hard to implement improvements - such as "bugzilla monitoring".
> >
> > I think I am not the only one who frequently felt frustrated submitting yet
> > another bug, knowing that it had more 50% of chance to disappear the
> > "oubliettes". I think there is an objective question: if bugs are not
> > followed up, that should not just happen by accident - there should be an
> > explicit and justified decision. There is also a subjective question: a user
> > who went through the pains to write a good bug report should get a feedback
> > with a followup, even if there are no "comments" in the bugzilla data base.
> >
> 
> Well, let me put it this way, a bug report will go unfixed in the
> following cases:
> - Triage work ends when the bug report is assigned to the maintainer;
> if the bug has no maintainer then the chances that it'll get fixed are
> a bit lower (some packages have no maintainer but are used by a lot of
> users so it gets fixed any way)
> 
> - The package has a maintainer but he's overworked and has a huge
> backlog, unfortunately that happens to everyone, in this case posting
> a new comment in the report should bring it back up in his list;
> pinging a bug report is the reporter's responsibility (triage team is
> always understaffed so to speak, too many bug reports, too few people
> to triage them all); so if after say a week of reporting a bug you get
> no response from the maintainer feel free to ask in the report.
> 
> It's always nice to acknowledge a bug report but unfortunately that
> doesn't always happen... you have to understand that a lot of bug
> reports go in per day (it also seasonal, i.e. towards the end of the
> development cycle the amount of bug reports increases considerably).
> 
> Another point is, there isn't a bugzilla where some bug reports don't
> go forgotten, again ideally this shouldn't happen, but there's ideal
> and there's what really happens :/

Technically, we have a ratio of X testers per Y developers ( by
developers, i mean people who are able to fix a bug, and by testers, i
mean people who can and will report a bug, ie, developers count as
testers as long as they use the software ).

X is always greater that Y, cause every developer is also likely to use
the software he write, at least on free software projects. 
So, for a single man project without any other users ( like a small
shell script ), the ratio is 1 per 1. So the developer is able to take
care of all bug reported by himself.

On a distribution linux project ( let's take Fedora because I have the
number http://fedoraproject.org/wiki/Statistics ), the ratio is :

- around 20 millions of users ( while the number can vary, i doubt there
is a 50% delta in the number ), let's imagine there is 1 million of
users, or the contrary 50 millions.

- 1075 packagers in their account system.

Which make a ratio between 1/1000 ( worst case in term of users ) or
1/50000 ( best case in term of users ).

Now, let's imagine that all of the 1000 packages are full time. Ie, work
8h per day 5 day a week on the project. This make 2800h ( which is more
than the 1680 hours we have in france, without counting holidays ). 

This basically mean that each users can have a exclusive slot of between
3 minutes to 3h of a developer time per year. This is not much, since
debugging can be tricky. Now, you add the fact that 
1) developers cannot do only bugfixing, sometimes, you need to do new
packages, or write new code.
2) developers have others occupations ( like going in holidays, writing
reports, discussing on ml, meetings )
3) most developers are not full time on their project.

Theses 3 points likely dramatically reduce the time that can be devoted
to bug fixing and bugzilla.

So how can this be improved.
 
We can either reduce X ( ie number of users ), or increase Y ( number of
developers ). We can also try to improve the efficiency of developers.

Reducing X, ie less users/testers, is not really a good option.  

Increasing Y, or developers efficiency requires almost the same step :
move people from the users/testers group to the developers group.

And first step is that people should try to fix their own bug as much as
possible. This way, they learn to do bug fixing, the process scale ( ie,
we will be nearer on a proper ratio of 1 to 1 if everybody fix his own
bugs first ). 

If we want to increase number of developers, the best way is to have
users who care about the software ( since they report bugs ) to be able
to fix bugs, ie become developers, or at least helping as much as
possible ( ie, giving very precise step, giving patches, triaging others
bugs so developpers do not have to do it, etc ). This way, there is more
time devoted for each problem, and more knowledge for all, and more
empowerment.

Now, that's just a goal, and while I doubt that everybody has the time
or the envy of becoming developers ( since others areas are equally
important, imho, and that mean others area also outside of the
project ), I think this must be clear that it is a question of community
sustainability. We know we cannot attain the 1 per 1 ratio, but we must
strive for it.

More developers mean better software, better software mean more users,
more users means more work for developers. So we need to find a way to
increase developers numbers at the same time that users number grows.

In commercial world, that's easy. More users equal more money, which
mean more developers paid ( that's a rough simplification, but that's
good enough ). 


In the community world, this is not as straight, unfortunately, because
more users do not mean more developers ( not automatically ). And while
we try to do our best, I am sure there is possibility of improvement. 

But before improving, we first need to start :)

So to conclude, as arrogant and elitist it will sound, the best way for
everybody to have a bug fixed is to fix it yourself.
-- 
Michael Scherer