diff options
Diffstat (limited to 'zarb-ml/mageia-discuss/20100925/001191.html')
| -rw-r--r-- | zarb-ml/mageia-discuss/20100925/001191.html | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/zarb-ml/mageia-discuss/20100925/001191.html b/zarb-ml/mageia-discuss/20100925/001191.html new file mode 100644 index 000000000..44b30784b --- /dev/null +++ b/zarb-ml/mageia-discuss/20100925/001191.html @@ -0,0 +1,193 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-discuss] Think about bugzilla monitoring? + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Think%20about%20bugzilla%20monitoring%3F&In-Reply-To=%3C1285406029.12505.259.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001152.html"> + <LINK REL="Next" HREF="001196.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-discuss] Think about bugzilla monitoring?</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Think%20about%20bugzilla%20monitoring%3F&In-Reply-To=%3C1285406029.12505.259.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-discuss] Think about bugzilla monitoring?">misc at zarb.org + </A><BR> + <I>Sat Sep 25 11:13:49 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001152.html">[Mageia-discuss] Think about bugzilla monitoring? +</A></li> + <LI>Next message: <A HREF="001196.html">[Mageia-discuss] Think about bugzilla monitoring? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1191">[ date ]</a> + <a href="thread.html#1191">[ thread ]</a> + <a href="subject.html#1191">[ subject ]</a> + <a href="author.html#1191">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le samedi 25 septembre 2010 à 07:57 +0300, Ahmad Samir a écrit : +><i> On 24 September 2010 14:58, Juergen Harms <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-discuss">Juergen.Harms at unige.ch</A>> wrote: +</I>><i> > Picking up from where Mageia forked off, many things activities look like +</I>><i> > continuity from Mandriva Linux. But forking is also a challenge to find not +</I>><i> > too hard to implement improvements - such as "bugzilla monitoring". +</I>><i> > +</I>><i> > I think I am not the only one who frequently felt frustrated submitting yet +</I>><i> > another bug, knowing that it had more 50% of chance to disappear the +</I>><i> > "oubliettes". I think there is an objective question: if bugs are not +</I>><i> > followed up, that should not just happen by accident - there should be an +</I>><i> > explicit and justified decision. There is also a subjective question: a user +</I>><i> > who went through the pains to write a good bug report should get a feedback +</I>><i> > with a followup, even if there are no "comments" in the bugzilla data base. +</I>><i> > +</I>><i> +</I>><i> Well, let me put it this way, a bug report will go unfixed in the +</I>><i> following cases: +</I>><i> - Triage work ends when the bug report is assigned to the maintainer; +</I>><i> if the bug has no maintainer then the chances that it'll get fixed are +</I>><i> a bit lower (some packages have no maintainer but are used by a lot of +</I>><i> users so it gets fixed any way) +</I>><i> +</I>><i> - The package has a maintainer but he's overworked and has a huge +</I>><i> backlog, unfortunately that happens to everyone, in this case posting +</I>><i> a new comment in the report should bring it back up in his list; +</I>><i> pinging a bug report is the reporter's responsibility (triage team is +</I>><i> always understaffed so to speak, too many bug reports, too few people +</I>><i> to triage them all); so if after say a week of reporting a bug you get +</I>><i> no response from the maintainer feel free to ask in the report. +</I>><i> +</I>><i> It's always nice to acknowledge a bug report but unfortunately that +</I>><i> doesn't always happen... you have to understand that a lot of bug +</I>><i> reports go in per day (it also seasonal, i.e. towards the end of the +</I>><i> development cycle the amount of bug reports increases considerably). +</I>><i> +</I>><i> Another point is, there isn't a bugzilla where some bug reports don't +</I>><i> go forgotten, again ideally this shouldn't happen, but there's ideal +</I>><i> and there's what really happens :/ +</I> +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 <A HREF="http://fedoraproject.org/wiki/Statistics">http://fedoraproject.org/wiki/Statistics</A> ), 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 + +</PRE> + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001152.html">[Mageia-discuss] Think about bugzilla monitoring? +</A></li> + <LI>Next message: <A HREF="001196.html">[Mageia-discuss] Think about bugzilla monitoring? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1191">[ date ]</a> + <a href="thread.html#1191">[ thread ]</a> + <a href="subject.html#1191">[ subject ]</a> + <a href="author.html#1191">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-discuss">More information about the Mageia-discuss +mailing list</a><br> +</body></html> |