MeeGo wiki - User contributions [en]

Quality

2011-06-22T11:18:53Z

Jaritah:

= Quality =

This page is for MeeGo Quality Assurance related material.

== Projects ==

For all test reports see [http://qa-reports.meego.com http://qa-reports.meego.com]

{| border = 1 valign="top"
! Release
! Core OS
! Handset UX
! Tablet UX
! Netbook UX
! SDK
! In Vehicle Infotainment
|-
| Release 1.3
|
* [[/Plans/MeeGo Core Test Plan | MeeGo Core Test Plan]]
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [http://qa-reports.meego.com/1.3/Core Core Test Reports]
* [[Quality/CoreQualityMetrics | Quality Metrics]]
|
* [[Quality/Plans/Handset UX test plan|MeeGo HandSet UX Test Plan]]
* [http://meego.gitorious.org/meego-quality-assurance/handset-ux-tests Test Suite]
* [http://qa-reports.meego.com/1.3/Handset Handset Test Reports]
|
* Tablet UX Test Plan
* Tablet UX Test Suite
* [http://qa-reports.meego.com/1.3/Tablet Tablet Test Reports]
|
* Test Plan
* [[Quality/Netbook_Test_Suite_and_Utilities|Test Suites and Utilities]]
* [http://qa-reports.meego.com/1.3/Netbook Netbook Test Reports]
|
* [[SDKTestPlan|Test Plan]]
* Test Suite
* [http://qa-reports.meego.com/1.3/SDK SDK Test Reports]
|
* [[/Plans/IVI Test Plan | MeeGo IVI Test Plan]]
* IVI Test Suite
* [http://qa-reports.meego.com/1.3/IVI IVI Test Reports]
* [[Quality/IVIQualityMetrics | Quality Metrics]]
|-
| Release 1.2
|
* [[/Plans/MeeGo Core Test Plan | MeeGo Core Test Plan]]
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [http://qa-reports.meego.com/1.2/Core Core Test Reports]
* [[Quality/CoreQualityMetrics | Quality Metrics]]
|
* [http://wiki.meego.com/Quality/Plans/1_2_Handset_UX_test_plan MeeGo HandSet UX Test Plan]
* [[Quality/TestSuite/handset-test-suite|Test Suite]]
* [http://qa-reports.meego.com/1.2/Handset Handset Test Reports]
* [[Quality/HandsetQualityMetrics|Quality Metrics]]
|
* Test Plan
* Test Suite
* [http://qa-reports.meego.com/1.2/Tablet Tablet Test Reports]
* [[Quality/TabletQualityMetrics | Quality Metrics]]
|
* [http://wiki.meego.com/Quality/1.2NetbookTestPlan 1.2 SW Update Test Plan]
* [[Quality/Netbook_Test_Suite_and_Utilities|Test Suites and Utilities]]
* [http://qa-reports.meego.com/1.2/Netbook Netbook Test Reports]
|
* [[SDKTestPlan|Test Plan]]
* Test Suite
* [http://qa-reports.meego.com/1.2/SDK SDK Test Reports]
|
* Test Plan
* Test Suite
* [http://qa-reports.meego.com/1.2/IVI IVI Test Reports]
* [[Quality/IVIQualityMetrics | Quality Metrics]]
|}

== QA tools ==

Quality assurance tools are developed to ensure MeeGo SW quality. They are developed and maintained by QA tools team.
* [[Quality/QA-tools|Meet the team and find our tools]]
* [[Quality/QA tools development|Participate in development activities]]. You are most welcome!

The following links provide some basic information on QA tools and their usage.
* [[Quality/QA-tools/How_to_set_up_repositories|Setting up the repositories for installing tools]] (please note that not all tools are in these repositories yet)
* [[Quality/QA-tools/Test packaging|Test packaging]]: Test packaging is the mechanism to wrap any tests in rpm packages to automate execution.
* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]: A guide for setting up automated testing environment. It includes instructions how to automate test execution and image installations.

== Procedures and best practices ==

* [[Quality/Plans/Testability-checklist|Feature Testability Checklist]]
** The basic intent of the feature review is to make sure that all features/requirements defined for MeeGo release are '''testable'''. The target is to map test cases in Distro testing against requirements, so we can determine whether features are '''done'''. This checklist / guideline should be used when reviewing MeeGo's features. Review comments will be given based on this checklist.
* [[Quality/Testability-commenting|Testability Commenting Guide]]
** This is a guide for QA contacts about how to comment on feature testability so as to provide as much information as possible to test developers.
*[[Quality/TestSuite/MCTS/MCTS_Development_Guideline | MeeGo Core Test Suites Development Guidelines]] <br>
*[[MeeGo Core Test Suites Packaging draft]] <br>
* [[Quality/Plans/Test-plan-template|Test plan template]] -- PROPOSAL, please contribute
* [[CompTestPlanTemplate|Component Test Plan Template]] -- WORK IN PROGRESS, please contribute
* [[Quality/Test_case_template|Test Case Template]] -- Updated, ready for approval
* [[Quality/TestDesignProcessAndGuideline| Test Design Process and Guideline]] -- WORK IN PROGRESS, please contribute
* [[Quality/TestSetGuideline| Test Set Guideline]]
* [[Quality/Test management overview|Test management overview]]

== Defect tracking ==

* [[/defects | Defects Management]]
* [[/Bug_Life_Cycle_and_Handling|Bug Life Cycle and Report Handling/Follow-up Guidelines]]
* [[/Bugzilla_Fields|Fields in a bug report]]
* [[/Bugtriage | MeeGo Bug Triage]]
* [[/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]] -- WORK IN PROGRESS, please contribute
* [[/SysDebug | MeeGo Sys-Debug]] (finding the right component for a report)
* [[/How_To_Report_Bugs|How to report bugs]]
* [[/Bug_Access_Restrictions|Bug Report Access Restrictions]]
* [[MeeGoBugzilla_Customization|Bugzilla customized features]]
* [[/MeeGoBugzillaRequestProcess|Requests for changes in Bugzilla code/UI itself]]

== Error Management ==
See the [[Quality/Error Management]] subpage.

== Compliance Program ==
[[Quality/Compliance | MeeGo Compliance Program]] - the compliance spec (initially)

== Contact ==

* Mailing List: [http://lists.meego.com/listinfo/meego-qa MeeGo-QA]
* IRC: Channel #meego-qa on irc.freenode.net

== Meetings ==

General QA Meetings are held weekly on Tuesdays 07:00 UTC in the channel #meego-meeting on irc.freenode.net. [[Quality/Meetings|Click here for more information.]]

QA Tools meetings are held weekly on Tuesdays 08:00 UTC in the channel #meego-meeting2 on irc.freenode.net. [[Quality/QA-tools/Meetings|Click here for more information.]]

For information on triaging meetings for specific areas [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings|click here]].

== See also ==

* [[/Glossary | QA Glossary ]]
* [[/Test_areas_and_types | Short descriptions for Test Areas/Types]]
* [[Quality/Plans/Quality-considerations|Quality Considerations / Testing Quality Characteristics]]
** Some ideas around testing quality characteristics hopefully helping you identify what kind of things could be checked from applications - can be used as a frame to define test considerations – as a set of logical test cases - for applications targeting to run on MeeGo.

== Questions and Answers ==

* What is the QA contact expected to do actually?
** QA contact work with/support/advice/help package maintainers (see Fedora example [[http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility ]] or MeeGo guidelines for maintaining package [[http://wiki.meego.com/Packaging/Guidelines#Maintaining_a_Package ]]) and other users on QA related issues/questions for component in case.
*** Features ("Once a requirement is integrated, MeeGo QA verifies it by running the corresponding test cases." from [[https://meego.com/developers/requirements ]])
**** make testability analysis for features (yes or no value to testability field) and
**** identify "feature acceptance tests" together with product management and package maintainers that could be used at the end as a criteria for feature status to be changed as "VERIFIED".
*** Bugs ("QA Contact or Bug Submitter verifies bug fixing with the "how to re-produce" instructions in the original bug report when the bug is marked as RELEASED - FIXED." from [[http://wiki.meego.com/Quality/Bug_Life_Cycle_and_Handling ]])
**** facilitate the whole bug life-cycle from QA perspective, including ensure bug report completeness, follow up bugs by providing helpful or required information in timely fashion to accelerate bug fixing and verify the issue after fix is integrated, especially when the original reporter is not responsive or has difficulty to follow the bug up.
**** actively follow-up the bugs. Making sure the bug is attended properly, ping the default assignee or assignee or reporter to get visibility and comments on the progress, triage bugs, verify and close them whenever possible.

[[Category:QA]]

2011-04-26T06:34:52Z

Jaritah: /* Next Meeting */

== Logistics ==

Until further notice, the MeeGo QA meets every Tuesday at 07:00 UTC for one hour.
All MeeGo QA meetings take place in the MeeGo IRC channels:
* Main meeting: #meego-meeting
* Back channel & other discussions (optional): #meego-qa
Propose a topic in advance by editing this page (#Next Meeting). Please note the following before proposing a topic:
* Your topic proposal contains a title linking to a relevant page, and the names of the team or individuals proposing that topic.
* The people behind the proposal need to take part in the MeeGo QA meeting.
Resolution - Agenda is frozen approximately 18h before the meeting. If there is too many items then V-PV will pick the topics to be discussed.
* Topics proposed might be addressed through other channels as well, being answered through other channels or being forwarded to the right team.

== Next Meeting ==
'''Tuesday April 26th 2011 07:00 UTC''' - Agenda Proposal

This time we will be focusing different process and procedure related items. If time we will also have short period for questions to QA Leads. Please anyhow remember to update your verticals QA status.

* Opening and general news
* Actions from previous meetings (2011-04-19)
* Include test coverage analysis file in mcts test package directly
* Update to 1.2 QA Situation (QA Leads)
** Leads create short summary to Wiki min 1h prior the meeting so that in the meeting we can concentrate on questions and discussion
** [[Quality/Meetings/QA leads update 1.2| Weekly Updates from QA Leads]]
* QA-Tools update

== Logs ==
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-04-19-07.00.html 2011-04-19 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-04-12-07.01.html 2011-04-12 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-03-29-07.06.html 2011-03-29 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-03-22-07.08.html 2011-03-22 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-03-15-06.59.html 2011-03-15 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-03-01-06.59.html 2011-03-01 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-02-22-07.00.html 2011-02-22 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-02-15-07.00.html 2011-02-15 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-02-08-07.00.html 2011-02-08 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-02-01-06.59.html 2011-02-01 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-01-25-07.01.html 2011-01-25 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-01-18-06.59.html 2011-01-18 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-01-11-06.59.html 2011-01-11 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-01-04-07.00.html 2011-01-04 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-12-28-07.00.html 2010-12-28 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-12-21-07.02.html 2010-12-21 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-12-14-07.01.html 2010-12-14 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-12-07-06.59.html 2010-12-07 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-11-30-06.59.html 2010-11-30 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-11-23-06.59.html 2010-11-23 Meeting Minutes]
* [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-11-09-14.31.html 2010-11-09 Meeting minutes]

== Materials used in meetings - if not anyplace else ==
* [[Quality/Meetings/QA nominations 101201| QA Nomination proposals for 1st of Dec 2010 TSG Meeting]]
* [[File:QAtoolproposal.pdf]] - proposal about new QA tool discussed on Dublin QA Workshop (un-conference day)

Quality/Meetings

2011-04-19T08:06:18Z

Jaritah: /* Next Meeting */

2011-03-24T05:47:15Z

Jaritah:

'''Please note''' that currently the up-to-date information can be found at [[Quality|Quality wiki page]].

The MeeGo Quality assurance is one of the pieces in MeeGo Development Structure (see http://meego.com/sites/all/files/MeeGoDevStructureTSG_May5.pdf)

Today there is no procedure defined but we can improvise with some common sense.

=== Mission ===

Learning from the former labor at Maemo the QA team will actively conduct testing and simulations. The QA team will stimulate community participation in testing and quality efforts to make sure MeeGo is as usable and polished as competitor's smartphone OSs, or better.

=== Structure ===

==== Areas ====

The main areas within the scope of the working group are (in no particular order):

* '''Specifications''' : Identify new needed features or features that arise from user stories or bug reports and make a spec out of them.
* '''Documentation''' : Develop release notes documentation and workaround HOWTOs until a specific issue is solved.
* '''Testing Control Groups''': Organize control groups with members of the community for integrational testing (e.g. above unit level) of new major features or drastic UI or human-machine interface changes.
* '''Ongoing Testing''' : Through well defined test plans, do integrational/functional testing with each new feature, bug fix or a release (minor and major)
* '''Reduce load on bug-squads''': Bug trackers and bug squads should be the last resort. Proper *active* testing will make their work easier and lighter in load.
* '''Head to head spec extraction''': Doing detailed comparisons with other OSs to identify soft spots and spec out how to improve/fix them.

[Rudely added by V-PV - Feel free to remove/edit/include to original]

How about areas like (not in particular order either):

* Testing definition: Containing testing levels and testing types
* Test specifications: Defining how to document and store
* Performance (and other non-functional parameters) targets and quality of the "Requirements"
* Intented quality of the MeeGo releases
* Testing approach for MeeGo distributions
* Test planning, what is planned to be done and what is ongoing
* Test run (test results) repository
* Quality guidelines for developers: What should be done in Projects
* Compliancy testing of eg. applications

==== Rational ====

I have drafted what I envision as the desired procedures, building on the experience I gained through Ubuntu.

While bug squads are important and vital part of the development process, I think that centrally lead, milestone oriented QA team is the only way to get to the polish other smartphone OSs on the market display.

I propose to lead the efforts, do the wiki gardening and user story conversion to bug reports and specifications, and to recruit prospective community members that want in the game as a non-development, no prerequisite contribution entry point.

=== Process ===

==== Meetings ====

Please expand.

==== Tasks ====

'''Started tasks'''
* Have a subdomain '''qa/quality.meego.com''' -- the name will be qa.meego.com and request has been posted to IT.
** Reasoning for having qa/quality.meego.com subdomain: Open source software doesn't test itself. MeeGo relies on the testing efforts of community members to help find bugs and verify products. Not everyone may be cut out to hack on MeeGo's codebase, but anyone who can use a web browser and has a supported hardware can help us test it. In order to do that one needs to have collaboration space having test cases for contribution, test runs for participation and test results for viewing. In addition one could also have possibility to dip her or his toes into development with QA tools and test automation with QA core team.
* Define [[Quality/TestabilityChecklist|Testability Checklist]] for ensuring requirement quality - Please, contribute by commenting.
* Define [[Quality/TestDesignProcessAndGuideline|Test Design Process and Guideline]] - Please, contribute by commenting.

'''Suggested tasks'''
* Have a mailing list (or channel in discussion forum or decision for having certain tag (e.g. [QA]) in the beginning of the title.)
* Have a irc-channel
* I propose we start by getting a thorough specification of what functionality each currently available component (=package?) provides, and then create unit test plans to test cover it with every iteration of the release (minor/alpha/beta/RC/final).
* I then propose that we move on to integration test plan authoring, meaning to cover test cases of component X that is supposed to integrate with with component Y and Z and write test plans that verify the integration is working as expected. That of course would require us to first survey and specify what higher level functionality each integration combination yields.
* Define Testing approach for Release Creation (moment of involvements) and related quality targets
* Define Quality Guidelines for Projects / Application developers
* QA Process (Test Design, Test Asset management, Test Execution and reporting)
* How community members can efficiently contribute to bug triaging while following our processes?

'''Completed tasks'''
* Modify Quality Assurance wiki from Working Group format to Team area format (see http://forum.meego.com/showpost.php?p=3088&postcount=3)
* Have a role description for Test Collection Maintainer (a.k.a test suite maintainer) (see [[Quality/Glossary|Quality Glossary]])
* Agree the "acronym" used for Quality assurance (used for domain, mailing list, irc, etc.)
** qa and quality were the names suggested
** according "votes" given in email tread qa is the choice.
* Define test plan template (see [[TestPlanTemplate]])
* Define test report template (see [[TestReportTemplateCollection]]

=== How to contribute ===

See the Process section above for current approved work and proposed tasks.

==== Contributors ====

Coordinators of this working group:

* [http://meego.com/users/sivan Sivan Greenberg] - Veteran Ubuntu developer, QA and integration specialist. Interested in triage, reporting and automation.
* [http://meego.com/users/krohon Lew Krohon] - I like things properly done and I am willing to expend time on helping MeeGo. The QA Working Group seems the best place to use the few skills I might have.
* [http://meego.com/users/texrat Randall Arnold/Texrat] - Maemo Community Council member, former Nokia QA engineer for Maemo devices and best practices blogger. Facilitator for MeeGo User Experience Framework proposal and eager to implement and support QA best practices.
* [http://meego.com/users/Tippa Timo Paatola] - Principal Engineer, QA. Full disclosure: I am a Nokia employee.
* [http://meego.com/users/jaritah Jari Tahvanainen] - Testing Specialist being Testing and Quality Obsessed from both theory and practical point of views. Working for Nokia.
* [http://meego.com/users/vatula Veli-Pekka Vatula] - Head of Maemo SW Testing. Industry background of SW Development. Past years in Testing of different SW platforms and Products. Working for Nokia.
* [http://meego.com/users/vilvo Ville Ilvonen] - Quality assurance tools development for MeeGo and MeeGo Devices(Nokia). Nokia employee.
* [http://meego.com/users/Chaitra Shanthappa Chaitra] - Application Testing team for MeeGo. Working for Nokia.

=== Glossary ===

Some terminology for aligning ourselves can be found here [[Quality/Glossary|Quality Glossary]]. See and comment (maybe by using discussion area of the page).

=== History ===

Page was initially done as a proposal for working group. Format changed based on instructions given in http://forum.meego.com/showpost.php?p=3088&postcount=3

[[Category:Community]]

Build Infrastructure/Community Builder

2011-03-24T05:36:58Z

Jaritah: /* Getting Access */

The Community OBS is now part of meego.com infrastructure and supports several important kinds of development:

* Applications to run on MeeGo
* Surrounds: the MeeGo contribution and sharing area
* Team Repositories
* Personal Repositories

Having these areas allow us to support:
* Extras : MeeGo's community App store complete with QA via Extras:Testing
* Managing packages as part of their acceptance into MeeGo core
* Deprecating packages from MeeGo core
* A high quality distribution built around MeeGo core

= TOC =
(some ideas on scope - probably an intro and a link to a sub-page)
* Prerequisites (links to other resources like SDK)
* Getting access to the OBS
* Local installation (cover general and distro variations)
* Learning to use it (tutorials)
* Organising projects: Best practice and team usage (including branches, building against other prj)
* [[Build_Infrastructure/Community_Builder/Tips_and_tricks|Tips and tricks]] (bind mounts for git in local builds; cross-compiles; other clever tricks)
* What the Targets are for?
* Fremantle, Harmattan and others
* New architectures (armv5 or MIPS anyone?)
* [[Build_Infrastructure/Community_Builder/Common_pitfalls|Common pitfalls]]

== Getting Access ==

The current (Jan2011) mechanism for getting access is : you ask lbt/X-fade on irc and explain what you plan to do; you tell them your meego account; they say "done"... you sign in.

You use the credentials from www.meego.com.

People ask why it's not just wide open:
* We have limited resources (as yet we have 5 workers) and this keeps us aware of usage
* we had someone wanted to rebuild all MeeGo on armv6 ... but hadn't spoken to the arm porters
* some other people wanted to do closed source and didn't realise the "OSI approved licenses only" policy
* irc is a good captcha

It takes an hour for passwd changes to sync (ie on the hour, every hour). If you created a new account on meego.com, please wait an hour before requesting access. This will ensure the account has been synchronized to the community OBS.

----
stuff below is old and can be removed
----

The current version co-exists with the Maemo.org OBS and targets:
* MeeGo:1.0:Core : Latest Release

The plan is to add:
* MeeGo:Current:Core : Always points to the latest release snapshot
* MeeGo:1.0.80.1.20100514.1:Core : each weekly snapshot. See [[Release_Engineering/Release_Versioning|the release guidelines]] for an explanation of the numbering.

The deployment supports home:<user> based building only at the moment.

Community OBS Testing Volunteers

If you want to help with the development and/or testing of the community OBS please add your details below and ensure you contact lbt/X-fade on irc :-

* meego id, short introduction, relevant skills
* vgrade, wanting to get Meego up on O2 Joggler, none really on OBS but a background in integration testing
* kostaja, mobile linux pro and hobbyist, done several OBS installations and currently maintaining an own OBS instance.
* csdb, looking into helping with arm port, been playing with setting up local OBS for 1 month since I saw reference to it from meego.
* copyleft, already setup a local OBS and ready to build additional packages on MeeGo 1.0, experience of porting MeeGo to new x86 netbook, deb packaging.
* dl9pf, OBS developer, developer of the cross-compilation for MeeGo, Requires(pre): rpm - BuildRequires: OBS ;)
* matthewg, linux user, looking to help port packages to netbook and other editions
* schimmm, linux user, Experience in packaging for other distributions (. rpm) and happy to work with Meego Community :)
* amjad, Linux build engineer, experience in packaging for other distro, helping with arm port .
* miska, former openSUSE packager wanting to use rpm based distro on his mobile phone, obs & rpm packaging
* saviq, FOSS advocate, good knowledge of OBS (ran my own instance once), RPM / DEB packaging
* matscp, software developer, eager to run Meego in my mini2440 board! =)
* ddompe, embedded sw developer, want to work on meego for beagleboard, familiar with packaging and cross compiling environments, but new to OBS
* Tobren, embedded sw / gui developer, trying to port MeeGo to Arm11 aka ArmV6, i.MX35, long years of embedded linux/Qt experience
* huzefaf, embedded sw engineer, test the MeeGo port on Moorsetown and N900 platform, relevant experience in device driver development and OS porting.
* lamikr, embedded sw developer, want to checkout howto integrate some still on early development phase packages for meego
* sabotage, MeeGo Handset developer/maintainer/packager, existing package maintainer on build.meego.com for several packages but I have several "hobby" packages I'd like to be available on MeeGo that don't belong on official servers
* leinir, developer on Project Bretzn which is supposed to integrate various build services with various IDEs, with specific focus on MeeGo and Qt Creator.
* manish, embedded hw-sw developer, want to work on meego applications and make it work for arm devices, eager to run it on gumstix and smartq devices, can build and cross compile, but new to OBS
* leo0916, embedded system SE, want to port meego to the different device, I need to build some midware to fix some problem, Now I work on the devkit8000.
* [http://meego.com/users/fabo Fathi Boudra/fabo] Debian/KDE/MeeGo developer/maintainer

(all accounts above enabled 19 Nov 2010... from now on just ask lbt/x-fade on irc or via email - also, please help document the process)