From Mageia wiki
Jump to: navigation, search

This page is about Mageia 2 post-mortem. All teams should add below things that should be improved but also the one that worked well and thenwe should keep.


What worked well that we should keep

What should be improved and why ?

  • jq - freeze window was way too large for perl.

at the time of writing, i have 350+ packages that need to be updated. the fact that window was large and extended afterwards to cope with new -rc is the problem. could the freeze window be relaxed on some very specific packages such as perl modules? at the minimum, i think we should strive for a shorter freeze window - even if i understand why we freeze (qa++).

  • ovitters - I didn't fix a lot of bugs before Mageia 2 release
  • alien - 2 things: some features were fixed at the very last moment & imho there wasn't much testing early on in the release, which made bugs appear late in the schedule.
  • doktor5000 - complete ruby stack was left non-updated and essentially umaintained after mga1 release, possibly due to absence from shikamaru, such single points of failure shouldn't happen
  • marja - I merged two of doktor5000's lists of most frequent forum support issues (some things might, in a way, be mentioned twice):
    • unbootable systems (those were really frequent, and severe as users experiencing such stuff are easily scared away and lose trust, which is comprehensible)
    • if a user has nonfree and tainted repositories enabled, mgaapplet should respect that during upgrade bug 6061
    • the nonfree driver issues (errata)
    • systems not booting when some uncommon filesystems are in fstab (errata)
    • networkmanager conflicting with net_applet for many people in the forums after upgrades bug 3344
  • malo - lack of packagers for large chunks (Java, Ruby): we need to accelerate the mentoring program to get more people involved (still too many unmaintained packages). Many packagers (and apprentices) went to sleep during the freeze period (basically until release), especially if they were invovlved in non-critical software: maybe there could be a better involvement of packagers for qa (set-up theme qa/packager teams for games, science, programming, sound, etc, subsystems).


  • online translation system
  • svn change notification
  • list of software for translation
  • list of webpages
  • more regular meetings (rotating schedule for other parts of the world)
  • more coordination with doc, dev and atelier
    • Not a good communication between devs and translator that result of some strings still in 'fuzzy' mode and so not translated even after the release.

Most important: more organization


What went great

  • Contrary to our expectations, the help texts for installer were translated, even translated into seven languages
  • We didn't expect to have an online installer help with a table of contents and a search field, but we do have it
  • We managed to finish the installer help, in spite of having to start again (from scratch, this time) when we had already done a lot.

What needs improvement


  • We had to start anew after having done quite some work - something like this can happen again if, e.g. we make documentation for MCC and find out later MCC gets fundamental changes or is replaced.
  • We should continue to make our help texts easier to understand.
  • In the install documentation and other documents we should give examples of best practice, such as having the /home directory (as example) on a separate partition or HDD, This makes it easier to reinstall, or perhaps change distribution as all your personal files and settings are retained.
  • Examples should be described using the command line in the first instance, followed by the GUI alternative. This is because it's easier to write a wiki page with cut-and-paste examples in <pre></pre> boxes than making and uploading multiple screenshots and explaining which button to press in each different GUI. This also has the advantage of demystifying the command line for new users as they will see that it is not as hard or frightening as they thought.
  • The documentation should give useful hints and tips as well as encourage good working practices and give reasons why a particular approach is advocated, and why it should be done that way.


  • There was a vast lack of knowledge about DocBook XSL. This is something we need to work on
  • It wasn't always clear to the translators what had changed in a file - this is something we need to work on
  • Write a template for developers, so that it becomes easier to documentate the packages. (Tobi_)
  • Brainstorming Idea: All developers have to documentate any changes on code --> like in BSD-Systems (Tobi_)
  • We should improve the collaborative writing methods:
    • The wiki was used, is it the best method? Should we keep using the wiki or try etherpad ?
      • (marja) We skipped that method when we started to work directly in Calenco. Calenco is great to work with a team on the same documents, as long as you don't forget to lock a file when you're working on it. The only downside is, that we can't easily compare the current version of a file with an older one. A very big plus about working with Calenco is, that changes are shown in the online help here within a few minutes. Is comparing versions with etherpad easy?
    • we should write a wiki page on how to do it so that new contributors could learn easier
  • We lacked certain technical competences :
    • Calenco management and work-flow (particularly for translation),
    • XML/XSL knowledge,
    • Knowledge of how the installer works (Where are the buttons? What page does that link to? How to change/add some?),
    • Licence guru...

We need to learn those competences (at least two people per bullet point) to be more independent and effective, to avoid having to keep asking favours of others who may begin to resent our ineptitude as time goes on ;-)

  • scsijon: A number of packages either changed names, became redundant or were newly created. What about a table wiki page defining, cross-referancing and explaining all (yes it will be big). It would contain names, not the individual versions.
    • In doc team meeting we agreed that this isn't a doc team task



  • MrsB: ISO testing brought QA together as a team and gave new people a reason to contribute. We hope to retain as many as we can and develop and grow the team further. Until this it had mainly been two people but with some mentoring I hope some of those who helped with ISO testing will become involved in validating updates.
  • MrsB: It raised the profile of the QA team and the work we do.
  • MrsB: The pad worked well as a collaborative tool.


  • MrsB: We had no policy in place for updates which are required on both mga1 and mga2 so we have seen updates begin to come through clumped onto one bug, which is not workable for QA purposes. To perform reliable QA we require separate bugs for mga1 and mga2. This is being addressed now.
  • MrsB: We are missing some useful help for people who are willing to participate in validating updates to begin doing so. I'm working on adding that now.
  • MrsB: People have complained of hardware which worked in the betas being broken in the release.(see next point)
  • MrsB: Lack of modern hardware and variety of hardware within the team to test with.
  • MrsB: The Live CD's not being available until later in the process put some people off testing those releases. Not within the team but outside of the team, others have said they would like to test but there was no Live CD available. I'm sure some could no doubt have been convinced to test further and become part of the team.
  • MrsB: The infamous Bug 2317 was allowed to remain unresolved, also lowered in priority, to remain for the life of mga2!
  • scsijon: no dual-cd until beta3 so those of us awaiting were sitting on our hands.

Ideas for improvement

  • MrsB: Grow the team to add people and hardware.
  • MrsB: Allow extra time for testing the Final pre-release. The final stages were rushed, with a last minute ISO set. It would be better IMHO to allow an extra week or extra few days in final testing to iron out the wrinkles and address as much of the errata as possible.
  • MrsB: Fix bug 2317 (Pretty please!)(With a cherry on top)
  • MrsB: Implement Stormi's suggestion to use mga2 errata for test cases for mga3 testing.
  • MrsB: Automate alot of the basic testing. There are various ways to do this..
  • MrsB: Investigate the possibility of virtualising hardware.
  • derekjennings: It would be nice if we could test an online upgrade before final release. Perhaps by have an option switch in mgaapplet to use Cauldron instead of the release repository.

(MrsB: This can be done with mgaapplet --testing but we obviously need to document it better)

  • scsijon: What about a set of pre-created standard testing doc's? Containing things like: what needs to be tested in each individual hardware case, what results should be expected, what the bugzilla error formats should be in and contain or attached.
  • scsijon: Have a 'page' where testers can provide basic information (something like the lighthouse sys-info report to show what has been tested against) on each set of the hardware they are testing against, both to show duplications (wanted,) especially to compare if a problem exists on one and not another.
  • scsijon: Allow a way to assign a rgb code to each tester for the Etherpad colours and give the testers the ability to put their code in on the page. I did like the Etherpad system!
  • scsijon: What about another build cd containing those in the "other desktops" group.
  • scsijon: Split each of the two main dvd's containing the 3 main graphical environments (KDE, GNOME, LXDE - e17) into two individual levels, one containing the 'base only' and a second dvd extending the first with apps.



  • leuhmanu's greasemonkey script made work a lot easier
  • we're a peaceful team


  • In the Tracker bugs, there was a mix of enhancement and critical bugs in the same tracker, we should avoid that to have a better process,
  • Not an easy way to contact/assign to specific i18n team a bug as most of them don't read the main ml.
  • We don't know if devs/maintainer are still active (cjw/supp/shika)
  • Some team/maintainer have never replay to any bugs even if there are still active, and sometimes try to fix a package when we have a patch in the bugzilla...
  • We don't know if the bug is correctly assigned
  • The bugs with the junior_job/patch keyword seems not really popular for people
  • Some bugs have received no action from our part

To Improve

  • Make a script to check if the package request are now in the current release (csv + urpmq ?)
  • Our communication with devs
  • Have a precise list for mass ping/eol bugs, make sure we have all exception we want


What went well

What needs improvement


What went well

  • Most artwork was received well.
  • There was good community involvement in providing the default background.

What went not so well

  • Very late in choosing final background.
  • Confusion over flickr sites - this should be either solved by bug[1] or better communication with other teams.
  • MCC icon wasn't well received by the community.
  • Website branding does not match release.
  • For a few months the team was pretty innactive.
  • The final release was rushed; the finished product isn't as polished as it could be.
  • Only one person on the team has commit rights to svn, so for any work to be finalized we had to wait for him or ask someone else to do it for us.

What do we need to improve?

  • A clearer roadmap is needed, with defined goals and deadlines.
    • We finished the theme with very little time for testing.
    • The team was innactive for a while, therefore the finished product was rushed.
  • Ideally we'd have an online repository of artwork and work in progress that is visible to everybody.
    • Bring in more community involvment.
    • Crowd source feedback for the art direction from the userbase.
    • Attract more contributors.
    • Find real designers for general artwork (icons, web site...)
  • We need a better method for handling bugs.
  • Need to allow at least one other person on the team to commit to svn.


  • Sysadmin page with process for new release has been completed with more details.


  • Repository was not cleaned up after final uploads, leaving 3 orphan packages -- A comment has been added on the new release instructions page so that it is not forgotten for next release.
  • Branching of packages svn for Mageia 2 is based on latest markrelease commit. However some packages have been pushed to cauldron updates_testing repository, which is also running markrelease on the package, making the wrong version branched for those packages.


Went not so bad

  • Web site was released on time with a new home page
  • the new navigation scheme, bar and map have been deployed (still in the process)

To improve

  • There was essentially not much people in this team and work has always been done in urgency-mode; this does not help to plan in advance and maintain the whole website at large
  • there was no guidance on the release pages content and it had to be improvised
  • (partly as a consequence) the translation happened after the release
  • the translation tools need a serious overhaul, as the underlying framework
  • as a consequence of the new style (home, nav bar), pages contents have to be revised (more space, more designed layout).
  • there is a clash of identity between the project/organization site, and the product site; unfortunately, this will be hard to resolve as long as both have the same name.
  • we're lacking support for the identity.m.o app and LDAP backend (several bugs without a move in the past months)

How to improve?

  • excellent question
  • more brains, more hands


What went well

  • Forum has been running smoothly on a tech point of view.
    • No crashes.
    • No security flaws.

What went not so well

  • Moderation went rather well thks to Isadora (and Germ):
    • Very effective and accepted moderators the 2.
    • But others moderators were not so available: will need to be thought about (new moderators ?)
  • Technical support went well thx to doktor5000;
    • Very effective and responsive
    • But there is too much work for him now [INPROGRESS - help was offered]

What do we need to improve?

  • Features were not added & upgrade process sub optimal
    • Nearly freeze of administration and team building activities [SOLVED]
    • Internal difficulties needed to be solved [SOLVED: forums meeting with ennael helped a lot]
    • Problems of organization and split of forum admin activities between "sysadmins" and "forumadmins" [TOSOLVE]
    • No test forum for new features and acceptance tests before production upgrade [TOSOLVE]
    • Lack of PHP / PHPBB devs to help add features [TOSOLVE]
  • Missing direct access to database for mass maintenance/administration actions [TOSOLVE]
  • Missing direct access to uploaded data zones (avatars, files, iconsets) [TOSOLVE]
  • Moderation team could grow [INPROGRESS]
  • Helpers Team building needed to be started [SOLVED: doctor5000 in charge]
  • Team leader was not elected [INPROGRESS]

How to improve?

  • Item 1.
    • Sub item 1.