From Wiki [en] OpenMandriva
< QA
Revision as of 19:55, 27 June 2013 by Rxu (Talk | contribs) (create summary page)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Taken from the Etherpad (

This is the OpenMandriva QA Meeting Pad for June/July 2013.
Meeting topics and minutes are debated below, as shown by the agenda.
Users are free to add their own topics for discussion.

Make sure to stick with one colour! We don't want to be confusing.
(Please also use distinct colors >_>)

Please note your name in the bulleted list below, so we know who you are:
  • Robert Xu
  • Colin Close
  • Chris Tanner
  • Ben Bullard
  • arisel

Meeting Agenda:

Release Procedures (incl. Pre-Release Testing & Approval)
Follow up with Colin's doc for release testing <a href=""></a>
(needs slight modifications for live CD, but don't kill the old installer instructions either, in case we bring that back)
QA should test ISOs
QA and TC must work together, both must approve candidates for relases seperately before it may be considered or release.
Need a release manager, maybe bero? Who decides this?
  • Definition of Release Manager - Coordinator - make sure that things get done, must be knowledgeable with the process
  • The process of releasing a new version must be documented for release manager (e.g. release schedule & process)
  • [13:40:41] * arisel expects that the release manager will have to be able to fix at least some things on short notice himself. In a perfect world he would not have to do that. But as we're not overflown with devs someone has to be able to decide what is important and what not. For that some technical knowledge is crucial. If we follow a perfect world scheme we will not release.
  • TC decides Release Manager
Prioirties need to be decided, Cooker should tell us whatever needs to be prioritized in testing

Issues with the past alpha ISO
Bug 8 said it did not boot in VirtualBox as far as I can tell from the bug report It can never have been tested. I've only tested the 64bit version and I can confirm at least that; but not the 32bit.
I tested the 32bit version today and although I eventually got it installed you'd have to be very expert to do it. I'm interested on how focussed we are on vbox. This is about the 3rd time sth works fine on real hw as well as inside other virtualisations (eg qemu), but not in vbox. Maybe leave that (vbox-testing) for the final review? (if you're dependend on vbox we should do these bugs earlier, of course).

Available hardware to QA is an issue.
Testing Two-stage approach - first stage emulators (vbox, qemu, etc), accept hardware related issues. Second stage Real Hardware as much as possible. (e.g. 1st stage perfect env, 2nd stage non-perfect)

Cooker Standards & Enforcement
Given the embarassing clashing on the mailing lists... does QA have a role in this?
I believe that QA has a unifying role to play in the whole distribution. That is why standards are so important they encourage people to interact to work out a viable solution. Once that solution is written down and ratified it becomes everybodies business to ensure that they are complied with. If QA standards and procedures are seen to make real improvments in quality then people will use them because they actually make the work easier. 
Who writes the standards? I agree that QA standards are the concern of QA.

So essentially documentation, documentation, documentation.

[14:25:22] <colin___> One omportant this before we close this. Could the TC generate a list of standards that the think would contribute to the smooth running fo the distro
[14:26:01] <arisel> colin___: I could ask for this. I'm unsure on how specific the outcome will be, but I've an idea on where to aim.

QA Testing Standards (e.g. what should we be looking for?)
I'm currently working on the website; it's somewhat far from completion. However, I hope to have it working well soon. I'm using fuelPHP for now (but ack, PHP).
Sightly off the point perhaps but our main problem here is hardware and the fact that an install is a very time consuming thing. There are only a few of us at the moment which also limits the range of hardware that we can test on. I wonder if the cooker devs can help us here. I would have thought that is should be possible to reduce the number of packages installed to those that are essential for a booted running system up to the X server; we would only need xterm or one of the very lightweight window managers just to test that the graphics hardware is properly detected. A commandline switch could enable this mode.
I have published an initial testing standard/checklist which everyone has (I hope) seen. I don't believe we should do any less than this.  We cannot test every individual package without more support.
We should also test any packages that Cooker requests we give special priority to.

[see above release procedures]
[14:29:56] <arisel> just one point: I could provide you with a smaller iso which boots into kdm and where you can select icewm as window manager. So if that is helpful i can try to get bero or me to regulary build one of those..
[14:30:04] <arisel> or you could build one yourself.
[14:30:37] <arisel> (sorry this was for the topic we jumped over)

[14:32:00] <arisel> colin___: ok, will explain the process to Xu_R. Most of it is documented, but still needs editing of one script. think I'll make that configurable, though. Then it should be easy.
[14:32:28] <Xu_R> arisel: It's essentially iso-build-tools and modifying the script, yes?
[14:32:35] <arisel> colin___: +1 for filing branding bugs. I'm fine with any place of filing them.
[14:32:38] <colin___> ok will do we relly should remove the Moondrake terminal screen you get if you don't boot directly into X
[14:33:17] <arisel> Xu_R: yes. the list you want to use is omdv_small_but_stuffed.lst, and you have to change that inside the "build" script.

Some of OpenMandriva's software is still branded as Mandriva, which is a no-no. I've taken the liberty of rebranding some of the key parts, but I have not submitted them yet. Current omv_software information <a href=""></a>

Bugzilla Management (incl. Bug Assignment)
The new bugzilla will be some time yet. I have all the software installed. The next task is to hook up bugzilla to the database (they are on separate machines) Then finally the nginx front end. Infra have indicated that I should use ssl and certificates for the authentication. This is new ground for me. Good luck! If you need any help with nginx, ask me (my server runs nginx). I have also added bero and arisel to the om-qa-alerts list so that they can see Bugzilla alerts.
Good idea. Are they linked into this Etherpad?
Also thanks for the offer of help I might well take you up on it but I must try myself first otherwise I will never learn anything.
Update: Bugzilla and potgresql are now working together I have started on nginx configuration.

Proprietry Software Policy.
We need to establish which proprietry packages are going to be supported. I know that the Nvidia package is probably a must (Poor Ben) but I'm not sure about AMD/ATI. I would like to see Adobe Reader supported. Possibly Google Chrome (for YouTube).