From Mageia wiki
Jump to: navigation, search
(Things Mageia could host)
(Things Mageia could host)
Line 80: Line 80:
 
* 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. --[[User:Voodoodali|Voodoodali]] 14:04, 25 May 2013 (UTC)
 
* 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. --[[User:Voodoodali|Voodoodali]] 14:04, 25 May 2013 (UTC)
 
===== Things Mageia could host =====
 
===== Things Mageia could host =====
* A pad similar to parinux for the preparation of blog posts, release texts etc. Could be useful for other teams too.
+
# A pad similar to parinux for the preparation of blog posts, release texts etc. Could be useful for other teams too.
* 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.
+
# 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.
* A image gallery for the artwork collection process and as a user-facing and user-friendly download center.
+
# A image gallery for the artwork collection process and as a user-facing and user-friendly download center.
* SVN or similar repository for the storage of artwork so there is no confusion over what is the current versions.
+
# SVN or similar repository for the storage of artwork so there is no confusion over what is the current versions.
** If possible, make the two items above the same software OR easy to move from here to their.
+
#* If possible, make the items 3 and 4 the same software OR easy to move from here to their.
  
 
== Sysadmin ==
 
== Sysadmin ==

Revision as of 12:48, 26 May 2013

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)

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.

Documentation

What worked well that we should keep

  • Wonderful team ! lebarhon 15:17, 22 May 2013 (UTC)

What we should improve, how ?

  • Connected to the i18n team, see above. lebarhon 15:17, 22 May 2013 (UTC)

QA

What worked well that we should keep

What we should improve, how ?

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

Triage

What worked well that we should keep

What we should improve, how ?

  • like usually not all bugs were triaged

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)
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 their.

Sysadmin

What worked well that we should keep

What we should improve, how ?

Web

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 ?