From Mageia wiki
Revision as of 05:47, 16 July 2015 by Marja (talk | contribs) (Category:Postmortems)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

Packagers

What worked well that we should keep

  • the iso's we have now aren't bad. possibly we need to evaluate if CD media are still needed, we could have a small iso that is < 1GB, because doesn't everyone have DVDs? what do magazines do, these days? --alien 17:27, 22 May 2013 (UTC)

What we should improve, how ?

release schedule + features

we tried to improve the release and features, but we grandiosely failed, it's even worse than mga2... most of the development was after version freeze...

  1. we need to keep a better schedule wrt features, eg: setting in advance some dates (4) at which the feature pages needs to be updated and to be evaluated. this way people are reminded about their features and development can be done before version freeze instead of after.
    • not doable if we do not have more people implied. Also having features listed but not implemented is not really harmfull. Still features should be implemented before first beta.
  1. we should also be strict in that features need to be completely ready before version freeze (this means no bugs and tested by others). if it's not ready for this release, it could be for the next release. as much as features is nice to have, our release needs to be stable and well tested before having features.
  2. features need to be committed in one push, no gradual changes. this will allow us to have the point of no return much later. and thus improve stability. (be advised that you can still phase parts of your features.)
    • not doable. you cannot expect people to be fully available on Mageia. Having a planning should solve that point
  1. to make this workable, we need to have shorter freeze times, which methans less alpha and beta's. best would be to have an alpha about 4 weeks before version freeze, so that we know where we stand, a 1st beta could be one weeks after version freeze and 2 weeks later beta 2 , then one more week for release freeze. and one more week for the RC, then 2 more weeks for final. total version freeze: 6weeks. total release freeze: 3 weeks. (hopefully, this will make sure feature development will not be done after version freeze, like it was now). The good news is that due to less changes wrt features, (only bugfixes between version and release freeze), that it's easier to test everything.
    • again we need more alphas. Alpha is a good time to make a break and check the general status of the distribution and how things work together. The pb we have is the same as in other distros: teach people and motivate to have feedbacks before RC
  1. in order to not lose any time, we need to automate as much as possible all problematic parts: failed rebuilds, unmaintained packages, missing dependencies, (release critical bugs), rebuilds when stuff changes... etc...
  2. as seen on the mailing list, the idea is to keep cauldron as releasable as possible, which means we need to be strict even during cauldron that missing dependencies are fixed asap...
  3. we should have a different category for stuff that needs to be looked at for the release, but can't be done beforehand. something like release_critical, but not release_critical. eg: release_required or something... this will have better visibility on what exactly are bugs.
    • too much complexity is damageable for general management of all this

I know this seems ambitious and impossible, but i think that we cannot gradually improve, we need to improve in one big piece for this to work. If you think about it, we lost most time during QA and pre-release testing because of the rebuilds, features being developed during freeze, etc... besides, if we can delay 2 months or more for mageia 3, it's better to start short so we don't run too long... --alien 17:27, 22 May 2013 (UTC)

distributing critical knowledge

people having critical knowledge should document and/or mentor others into this. a good way to do this would be with SIG's and to formalize the dev team. --alien 17:27, 22 May 2013 (UTC)

i18n

What worked well that we should keep

  • The blog translation with a pad. lebarhon 14:49, 22 May 2013 (UTC)
  • The translation of the website using .lang files and our nice report page went pretty smoothly. There is still room for improvement, but that is mainly to be seen on the Atelier/Web part. -- Akien 20:43, 26 May 2013 (UTC)
  • Notification mailing list i18n-reports@ml.mageia.org created by booklm is priceless. Filip 12:16, 30 May 2013 (UTC)

What we should improve, how ?

  • The help translation. We lost translators and waste much time because the help translation process was complex and varying (wiki pages + ml + Calenco + xxe + add-on + ...). We must find lasting processes and software. Moreover, it isn't easy to separate the doc writing (by doc-team) and its translation (by i18n), in fact both were managed by doc team, adding to the confusion. Hopefully, Marja was there 24/24 7/7 but I don't think this way is satisfactory. lebarhon 14:49, 22 May 2013 (UTC)
  • So far, i18n has two jobs that have nothing to do together. Translation and solving software problems-for translation of course but it is not the expecting activity. Ninety per cent of the mails in the i18n ML are about software problems, a few about organisation, and not only one about help translation (Installer or MCC)! Volunteer translators, registred in the i18n ML have never known we were translating the MCC help (I am speaking about French translation only). I think we should make a new deal. Since translators must know how works the application they are translating about, they often also are doc writers. I suggest to mix doc-team and i18n-team and replace them by two other teams, the writers/translators and the doc-software technicians. Applications to write and translate doc are often the same. lebarhon 15:15, 22 May 2013 (UTC)
  • Consider better use of pads (or even other platform) for promotion matter (press releases etc) - e.g. the pad used for Mageia 3 was inaccessible at least to Estonian translator. (see Atelier's postmortem for a proposal to host our own instance of an EtherPad or similar)
  • Lack of web translation platform for software translation (since our Transifex instance was buggy at least since end of 2011, and Oliver had to investigate the setup of a Pootle instance but did not find time to do so) is a big drawback for many translators. Discussions must be held on what should be used for the next release cycle. Considering the various aspects of the translation job (strings, website, doc and blog), we need something integrated with SVN. Maybe consider relying only on SVN and on scripts which would provide a nice report of the translation status? (see KDE and GNOME translation systems and our website report page). -- Akien 20:50, 26 May 2013 (UTC)
  • Do we have notification on i18n-reports@ml.mageia.org also for *.pot and *.po files? Filip 13:08, 30 May 2013 (UTC)
  • Are precommit hooks working for us? Filip 13:10, 30 May 2013 (UTC)
  • We need web pages for Mageia 4 a few weeks before the release (preferably in alpha and beta stage)? Filip 13:15, 30 May 2013 (UTC)
  • We need more regular meetings! Filip 13:25, 30 May 2013 (UTC)

Documentation

What worked well that we should keep

  • Wonderful team ! lebarhon 15:17, 22 May 2013 (UTC)
  • The webhelps are great :-) (marja, May 27)

What we should improve, how ?

  • Connected to the i18n team, see above. lebarhon 15:17, 22 May 2013 (UTC)
    • a lot can be improved by using the SVN + po workflow of yurchor
    • if our documentation is included in Filip's script, we'll be better aware when something needs to be translated (marja-May 27) Remark: already done on May 4th.
      MCC help will follow later, when it has been added to svn/soft/i18n-tools/docs/.
  • We didn't watch the wiki well enough

QA

What worked well that we should keep

  • MrsB: The team worked well together as a team, the stronger helping those with less experience and all coordinating using the pad.
  • MrsB: The system we use with the pad/bugzilla/qa-discuss worked but it does result in some repetition. We've yet to find a better solution though.
  • MrsB: The wiki page, where ISO testers can register their details, helped to keep in contact with people about new builds.
  • MrsB: dorsync script made it easy for people to download and check md5, sha1 and dates of the ISOs, also helped greatly with dumping onto USB stick which is the method most commonly used by the QA team. It could be improved or rewritten in python/perl with a GUI and maybe look to incorporate ideas from ubuntu testdrive where it configures and boots a VM with the chosen ISO. It was requested it also enable people with less space available to more easily select a single or group of ISOs to sync & test. This would be made easier too with a decent GUI.

What we should improve, how ?

  • Kernewes: I really would urge the devs to consider giving QA more time for pre-release testing. One week is simply not enough to test in detail, especially when the early builds are not even bootable. I am having so many issues with the final Mageia 3 that I'm considering going back to Mageia 2, but I'm sure I could have picked up several of these matters at the pre-release testing stage if more time had been available. My available time is very fragmented and I can't always help very much during the particular week when help is most needed. In my opinion QA need two weeks for pre-release testing, even if that means a longer release cycle.
  • wilcal: I would like to propose a 3 -> 5 day kool down period just before release. This would be where Cauldron is frozen, the proposed iso's are generated and there are no updates or changes to anything. I notice that there were changes being made in Cauldron just 24-hours before the release ISO's were made public.
  • MrsB: Far too much dev work was left until the last week or so before release. Important fixes were being included right up to and including the day of release. Most of the issues being fixed were reported at alpha stage. A proper dev team would help with this. At the moment we put too much pressure on one or two people and rely far too heavily on them for this task, which is not sustainable and I think the root cause of this problem.
  • MrsB: Kind of the same but more general. Bugs reported by testers were not seen to be recieving any attention until the last stages of release, which is discouraging for the QA team, continually adding 'still valid' comments etc. This caused at least one person to leave QA, ironically quite early in the process. SIG's will help to alleviate this I think.
  • MrsB: As time went on we lost ISO testers, they drifted away. It's difficult to retain contributors in the QA team. It's not appealing to packagers and can be too complex for novices. The rsync and dd process to get an iso and dump it onto usb is a barrier to entry we need to work on. The dorsync script went some way to doing so but could be much improved if rewritten in python/perl with GUI or even just something like kdialog on top of bash and properly packaged. As mentioned above, maybe incorporate some ideas from ubuntu testdrive.
  • MrsB: The (self) promised wiki page explaining our use of pad, bugzilla, qa-discuss, what to test, how to test it, etc. has yet to emerge. Details were sent in emails as ISOs were ready for tests but proper documentation would help newcomers. Another barrier to entry.
  • MrsB: Some automated testing of the ISOs before handing off to QA, for things like ensuring all the applications start, basically work and close without error. QA team could help to create or even maintain testcases if there were infrastructure to do so. Maybe make use of sikuli or similar.

Triage

What worked well that we should keep

What we should improve, how ?

  • like usually not all bugs were triaged
  • we should not create a new "version" for the upcoming one in the bugzilla before she is released, or we will miss real bugs like in this cycle...

Atelier

What worked well that we should keep

  • Aiming to have the artwork integrated by the first beta - that way we get it done for release.
  • Early completion of release texts: press release, blog post, installer texts.

What we should improve, how ?

  • Schedule - one was made, but it wasn't kept. I (schultz) am looking for an online Gantt chart for the team as a whole
  • There was very little testing of artwork - again will be improved by better scheduling to allow for improved test times.
  • We still have no centralised location for artwork, dropbox helps but it is not ideal or universally used. Either we use it only, or get something on the MGA servers.
  • The use of pads for general notes should be promoted, with a standard place where we keep the links, the wiki has such a place but it isn't used, and doesn't really work. Better ML notification of ongoing work would help this.
  • The blog post didn't have used last background and logos --leuhmanu 20:42, 22 May 2013 (UTC)
  • We really need an svn system for artwork, to make sure that the final is known to be final.
  • Community involvement in release - we need to reach out to communities a lot earlier in the schedule, and keep that outreach up all through the cycle.
  • Consider better use of pads (or even other platform) for promotion matter (press releases etc) - e.g. the pad used for Mageia 3 was inaccessible at least to Estonian translator.
  • There was a general sense of confusion as to who was taking responsibility for what. Granted, using all-volunteer labor, this is unavoidable to some extent. But there should be some kind of task-to-person assignment capability so to avoid duplicate efforts and reduce confusion, especially as we get close to release. --Voodoodali 14:04, 25 May 2013 (UTC)
  • The Atelier section on the wiki needs to be reworked. Its two principal functions are unfulfilled:
    1. Potential new contributors can't find relevant and useful information about how they might help Atelier, and what we are doing.
    2. Before trying to setup a project management platform or other new tools which would require sysadmin work or external hosting, we should consider using the wiki for the management of our work. It present three main interests: accessible to all contributors, relative ease of use, and possibility to write down processes and howtos for each of our tasks (e.g. how to update Ksplash or Grub with new artwork). We should rely less extensively on the mailing list which are hard to follow on the long term (topics get easily forgotten). --Akien 20:25, 26 May 2013 (UTC)
  • Our various tasks have to be documented, see e.g. the problem of the website: It has been entirely made by rda for Mageia 2, and when Mageia 3 came rda was lacking time to help us on the matter. Hopefully leuhmanu, david, filip and I (with some help from rda) managed to handle the new website. But as a result, there is no new marketing content for Mageia 3, we did not have time to rethink anything. Rethinking the website should be one of our tasks for Mageia 4, but it starts with documenting the actual solution. --Akien 21:03, 26 May 2013 (UTC)
Things Mageia could host
  1. A pad similar to parinux for the preparation of blog posts, release texts etc. Could be useful for other teams too.
  2. A project management platform such as bloodhound for clear indication of who is working on what and what deadlines are in place. Could be useful for other teams too.
  3. A image gallery for the artwork collection process and as a user-facing and user-friendly download center.
  4. SVN or similar repository for the storage of artwork so there is no confusion over what is the current versions.
    • If possible, make the items 3 and 4 the same software OR easy to move from here to there. (Just adding the possibility of "owncloud" that was named in the discussions on this topic, though I don't know what it can be used for exactly -- Akien 20:34 May, 26th (UTC)

Sysadmin

What worked well that we should keep

What we should improve, how ?

Forums

What worked well that we should keep

What we should improve, how ?