This page is about Mageia 4 post-mortem.
All teams should add below things that should be improved but also the one that worked well and then we should keep.
Links to previous post-mortems:
Link to empty template postmortem:
Packagers
What worked well that we should keep
- The choice of isos are good (although dual is least used and possibly tested)
- Many features were implemented, thanks to new packagers
- No mga1/mga2 packages left
- No broken dependency
- Very close to 100% success in autobuild, mostly parallel build failures left
- Autobuild caught some late breakages
What we should improve, how ?
- Packages failing autobuild were fixed very late, causing a lot of changes after release freeze, autobuild should be running often earlier and there should be a call to fix them sooner.
release schedule + features
distributing critical knowledge
l10n
What worked well that we should keep
- Transifex transition bring new translators.
- Our web pages translation report expanded and served well.
- Script for those who avoid TX worked well.
- There are some good news about some automation.
- Git transition was demanding but we did it mostly well.
- Since Oliver steeped down 3 team leaders system worked out ok.
- What's the status for blog translations? AFAIK some were mostly inactive.
What we should improve, how ?
- Transifex transition bring new translators who are not present yet on ML.
- We should make our wiki pages a bit cleaner and current.
Documentation
What worked well that we should keep
I think that our "Official" documentation has a good level, even if it is not yet complete.
There is some languages added like, ukrainian, russian and estonian.
Our documentation is getting praised by reviewers now.
What we should improve, how ?
- The wiki is on a EOL version.
- This version lacks an internationalization feature.
- Our team hasn't a lot of active members.
- Only marja knows how to manage the publication from Calenco to rpm.
- The initial process installation, including choosing the media and preparation of support, is not covered in our official documentation (from Calenco). Some pages are on the wiki but could be in the "Official" part. We have to do this migration.
- lack of skilled people to write the MCC documentation, about networks mostly. The solution is only to get help from dev or QA.
QA
What worked well that we should keep
The patience and good humour of the qa team in trying circumstances.
What we should improve, how ?
Lewis (2nd go)
Some of what follows merits mailgroup discussion, some is Mageia political. For brevity I omit the justification for each point; but be assured it is not lacking. The aim is:
- Eliminate large amounts of *wasted* time.
- Make life smoother for everyone.
- To deliver a better product with less hassle.
1] What goes into the first release phase is what is meant to come out. NO development en route, neither Installer nor the product. ONLY *necessary* changes along the way: correction of faults, routine updates of included software. No release timetable before everything is in place.
2] Only *1* installer, Live+Classic.
3] A much reduced ISO set, e.g. minority desktops, full Gnome, full KDE. Each necessarily 32 & 64 = 6.
4] Keep the ISO umbrella directory *constant throughout* e.g. MageiaX, rather changing it at each phase (alpha1 ... final).
5] Deal with releasing phases by rolling the ISO tree out at the appropriate moment, e.g. to MageiaX-beta2.
6] Use short & simple ISO directory names, e.g. Gnome32, KDE64.
7] Keep them *constant throughout*.
8] Use short and simple elementary file names (within ISO directories).
9] Keep them *constant throughout*.
10] Enhance DATE.txt to include a line saying what ISO it relates to.
11] Include this *in the installed system* (so you know exactly what you are testing).
12] ISO builders should install & launch what they make (1 architecture) *before* giving them to QA, to ensure they basically work, are testable. To avoid fall-at-the-first-hurdle duff ISOs.
13] Address the huge amount of repetetive (or worse, no) QA feedback with a system where each fault is noted *once* at its first occurrence, tracked subsequently. Fault v ISO/phase.
Triage
What worked well that we should keep
What we should improve, how ?
Make a list of all no more active maintainer/commiter
list of the corresponding packages, and drop them, to reduce bugs: https://bugs.mageia.org/show_bug.cgi?id=13000
