[Libreoffice-qa] MAB. 3.6 to 4.0 migration. When?
pmladek at suse.cz
Tue Jul 30 02:42:57 PDT 2013
bfoman píše v So 27. 07. 2013 v 02:44 -0700:
> Petr Mladek wrote
> > About 3000 bugs were fixed for LO 4.1 [...] Only small part of them was
> > fixed via the MABs process.
> Code freeze for 4.0.x branch is set to end of October and branch will be
> EOLed in November, just in 3-4 months. Migrating 3.6 MABs to 4.0 MAB is like
> watching the same movie all over again - you know what will happen. Bugs
> will be confirmed, got MAB status (or not) and usually nothing will happen
> till next MAB moving round.
This is why I suggested to clean up the MAB list and do not blindly move
the bugs to 4.0 MAB.
> Probably all current MABs are reproducible in
> master, so should be marked against it and then backported (if possible) to
> 4.1.x or 4.0.x (if it is still alive).
> I think that all this MAB per branch procedure should be reinvented together
> with the devs - the question is how to get their attention to help users by
> fixing major and annoying issues, even by slowing down introduction of new
Nobody is perfect and MAB list is just a helper process. Here are some
MAB version nominated fixed open success
3.6 245 184 61 75%
4.0 138 124 14 90%
4.1 68 59 9 87%
So, we fixed nearly 90% of MABs for 4.0 and 4.1. Is it something bad?
I do not thing so. IMHO, it is a great success.
Why is the success worse for 3.6? I think that it is because of the long
standing bugs that were moved several times. I guess that there are at
least 30 of them. If we remove them, there still will be 184 fixed MABs
and only 215 nominated. The success will be 85% and will be close to the
Now, the main question is what to expect from MABs. Do we expect that
all bugs will be fixed? In the ideal world yes but we do not live in the
ideal world. The resources are limited and we need to prioritize.
I agree that bugs in the MAB list are annoying but are they really the
most annoying bugs from all the reported ones? I am not sure. Especially
the ones nominated by the reporter might be.
Unfortunately, it is a bit subjective. Let me use an allegory. Try to
imagine a country with many roads. The roads need some maintenance,
otherwise there will be many holes and it will be hardly usable. Now,
there is road A on the north used by 10000 cars every day and road B on
the south used 2 cars every day. The road A is far from road B, so the
two cars almost newer use the road A. It means that the broken road B is
the most annoying road for the two drivers. Even the other drivers
understand that it is most annoying for the two drivers but they have
their own preference.
Now back to prioritization. If you have only one repairing team and both
roads are broken, what road would you repair at first?
Well, this is easy with the roads because you just count the cars. It is
more complicated with software. We do not spy users, so the number of
users is always just a best guess.
This is why we could not have super strict rules about nominated bugs.
Only the clearly wrong nominations are removed. The others are left
there to avoid useless series of fighting comments. It is better to
spend time on fixing bug than fighting for priority.
In additon: the number of affected users is only one metrics. There are
+ how often it is used (once a year, month, week, day, minute)
+ is there a workaround and how complicated it is to find,
+ is it regression
In reality, there are some MABs that look the most annoying for the
reporter but others see it different. So, they are handled with lower
Of course, there are also bugs that are should get fixed with high
priority but they are hard to fix and it is hard to find a volunteer.
We need to find a way how to fix these. One possibility is to escalate
these via ESC. Another way might be to find a sponsor and paid support.
Another possibility is to do some advertising somewhere, ...
1. I do not expect that all MABs have to be fixed because the list
is not 100% objective and we live in a real world.
2. We need to clean up the list from time to time and the MABs move
is a good opportunity.
3. We need to improve advertisement for bugs that are very annoying for
most users but still somehow ignored
4. We might thing about better name. "Most Critical Bugs" might better
describe the current usage of MABs. Well, it might be a bit confusing
vs. the "critical" and "blockers" severity in bugzilla.
More information about the Libreoffice-qa