Mageia2 Postmortem

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.

Packagers

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

Documentation

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

Work

• 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.

Methodology

• 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
• 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?) and 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 the installer functions (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 ;-)

QA

Good

• 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.

Bad

• 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!

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)

Triage

• 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,

Artwork

What went well

The 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.

What do we need to improve?

A clearer roadmap is needed, we finished the theme with very little time for testing.

Sysadmin

Bad

• 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.