From Mageia wiki
Revision as of 19:49, 4 June 2012 by Max (talk | contribs) (What went not so well)
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.

Packagers

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

i18n

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

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

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,

Marcom

What went well

What needs improvement

Artwork

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.

Sysadmin

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

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

Web

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