archive-org.com » ORG » M » MERPROJECT.ORG

Total: 820

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • View source for FAQ - Mer Wiki
    Mer under Mer itself does not impose any particular license to the packages it is composed of The packages use various FOSS licenses such as GPL LGPL BSD and MIT For details you can query lisences on Mer based image with rpm qa queryformat NAME has license s LICENSE n Frequently Asked Questions for Vendors Vendor Jolla Frequently Asked Questions How does Jolla currently track work required for a release File Changelog ambianced png 200px thumb right An Example Changelog from a closed sourced package File Changelog ofono png 200px thumb lright An Example Changelog from an open sourced package Currently in Jolla OBS changelog the commits for https wiki merproject org wiki File Changelog ambianced png non open source packages are followed by a bug number which the commit contributes to Take the attached picture as an example of changelog with bug numbers for the ambianced package On the device the changelogs are reachable via rpm q changelog package name However for changes coming from https wiki merproject org wiki File Changelog ofono png open source packages the commits do not follow any bug numbers Existing open packages include some on Mer side such as mer core mer tools hybris hal common stuff essentially HADK https github com mer hybris some on Sailfish open bits https github com sailfishos and nemo mw In Mer projects looking at the changelog only shows the commit messages without any bug numbers so nothing is traceable from Jolla side by bug numbers When releases are made it s important to be able to track the changes from bugzilla Internal developers need to provide the release manager at least one bug which addresses to the changes they ve made for the new update As also mentioned earlier in https lists sailfishos org pipermail devel 2015 January 005571 html Jolla s porposal as one of Mer s vendors Jolla would like to ask the Mer package maintainers and the Mer community to please adopt a policy to require bug numbers in some commits to Mer packages to support vendor tracking of changes in Mer To have this tracking mechanism also on the open side developers can file a bug on Mer Bugzilla explaining the issue they have a fix for and then provide the bug number e g MER 12345 in the commit message they push to git This will benefit both sides as Mer can provide same kind of automation and tracking Jolla can cut down the manual effort required for tracking the changes in the open parts Jolla can move planning of open components to mer bugzilla How can providing a bug number reduce the manual work in tracking Before having the bug numbers for commits from the Mer community changes on the Mer side was tracked manually The reason to have this bug number is to be able to track Mer bugs on Jolla bugzilla and automate as much of the process as possible Basically there are three steps A bug gets

    Original URL path: https://wiki.merproject.org/wiki/index.php?title=FAQ&action=edit (2016-02-01)
    Open archived version from archive


  • Revision history of "FAQ" - Mer Wiki
    prev 13 13 7 December 2011 Vesku Talk contribs 842 Can I install Mer on device X and What license s is Mer under cur prev 12 37 7 December 2011 Vesku Talk contribs 30 What does Mer mean for End Users cur prev 09 46 6 December 2011 Sledge Talk contribs 259 Replaced broken links with one to FakeOBS What documentation is available to help me start development on Mer cur prev 06 30 10 November 2011 Vesku Talk contribs 609 Undo revision 266 by 187 52 30 3 Talk cur prev 04 13 10 November 2011 187 52 30 3 Talk 609 Will Mer provide GTK or deb packages or some other feature cur prev 13 18 10 October 2011 Micu Talk contribs 98 What is Mer and how can I learn more about it cur prev 18 13 5 October 2011 82 181 203 2 Talk 14 Minor grammar and style fixes cur prev 15 43 4 October 2011 76 26 109 40 Talk 765 Will Mer provide GTK or deb packages or some other feature cur prev 15 23 4 October 2011 76 26 109 40 Talk 704 What documentation is available to help me start

    Original URL path: https://wiki.merproject.org/wiki/index.php?title=FAQ&action=history (2016-02-01)
    Open archived version from archive

  • Pages that link to "FAQ" - Mer Wiki
    User User talk Mer Wiki Mer Wiki talk File File talk MediaWiki MediaWiki talk Template Template talk Help Help talk Category Category talk Filters Hide transclusions Hide links Hide redirects The following pages link to FAQ View previous 50 next 50 20 50 100 250 500 Main Page links Vendor Release Structure links View previous 50 next 50 20 50 100 250 500 Retrieved from https wiki merproject org wiki

    Original URL path: https://wiki.merproject.org/wiki/Special:WhatLinksHere/FAQ (2016-02-01)
    Open archived version from archive

  • FAQ - Mer Wiki
    base since in those projects usually target is to provide a complete OS with UI and HW adaptation See Community Workspace for information about available user experiences and HW adaptations As explained in What does Mer mean for End Users Mer itself is not targeted for end users so installing it makes only sense if you are developing Mer or porting the core itself to a new platform What license s is Mer under Mer itself does not impose any particular license to the packages it is composed of The packages use various FOSS licenses such as GPL LGPL BSD and MIT For details you can query lisences on Mer based image with rpm qa queryformat NAME has license s LICENSE n Frequently Asked Questions for Vendors Vendor Jolla Frequently Asked Questions How does Jolla currently track work required for a release An Example Changelog from a closed sourced package An Example Changelog from an open sourced package Currently in Jolla OBS changelog the commits for non open source packages are followed by a bug number which the commit contributes to Take the attached picture as an example of changelog with bug numbers for the ambianced package On the device the changelogs are reachable via rpm q changelog package name However for changes coming from open source packages the commits do not follow any bug numbers Existing open packages include some on Mer side such as mer core mer tools hybris hal common stuff essentially HADK https github com mer hybris some on Sailfish open bits https github com sailfishos and nemo mw In Mer projects looking at the changelog only shows the commit messages without any bug numbers so nothing is traceable from Jolla side by bug numbers When releases are made it s important to be able to track the changes from bugzilla Internal developers need to provide the release manager at least one bug which addresses to the changes they ve made for the new update As also mentioned earlier in Jolla s porposal as one of Mer s vendors Jolla would like to ask the Mer package maintainers and the Mer community to please adopt a policy to require bug numbers in some commits to Mer packages to support vendor tracking of changes in Mer To have this tracking mechanism also on the open side developers can file a bug on Mer Bugzilla explaining the issue they have a fix for and then provide the bug number e g MER 12345 in the commit message they push to git This will benefit both sides as Mer can provide same kind of automation and tracking Jolla can cut down the manual effort required for tracking the changes in the open parts Jolla can move planning of open components to mer bugzilla How can providing a bug number reduce the manual work in tracking Before having the bug numbers for commits from the Mer community changes on the Mer side was tracked manually The reason to have this

    Original URL path: https://wiki.merproject.org/wiki/index.php?title=FAQ&printable=yes (2016-02-01)
    Open archived version from archive

  • Quality/Test coverage - Mer Wiki
    armv7hl save Smoke testing Minimal set of tests for covering basic functionality of the Mer core Package pattern for smoke tests MerSmokeTests Test plan mer smoke test plan v0 1 xml Execute tests as root copy user s home user eat store env to root Test coverage Domain Test package Target of tests Status Comments Communications Bluetooth blts bluetooth bluez 28 Packged Some of the tests requires seconds device or accessories Communications Bluetooth mwts bluetooth bluez 44 Not packaged Uses Dbus interface Some of the tests requires seconds device or accessories Communications Cellular Framework blts ofono ofono 52 Not packaged Maybe out dated Communications Cellular Framework mwts ofono ofono 6 Not packaged Out dated Includes SIM functionality Core mwts filesystem 30 Not packaged Has USB mass storage tests too Core blts watchdog 3 Not packaged Core blts wlan core 11 Not packaged Requires WLAN Aps and another device Essentials Base Essentials blts usb libusb libusb1 4 Not packaged Mainly manual testing Graphics Display Graphics Adaptation blts fbdev xorg x11 drv fbdev 11 Packaged Requires framebuffer Graphics Input Adaptation blts input devices xorg x11 drv evdev xorg x11 drv keyboard xorg x11 drv mouse 11 Packaged Requires configuration Graphics OpenGL ES blts opengles2 perf llvm mesa 19 Not packaged Benchmark tests Graphics X11 blts x11 49 Packaged Includes benchmark tests Multimedia ALSA blts alsa core alsa lib alsa core 9 Packaged Requires configuration Multimedia Gstreamer Multimedia Codecs mwts gstreamer gstreamer gst plugins bad free gst plugins base libogg libtheora libvorbis 180 Not packaged Requires test data Audio and video test cases Qt Qt Qt Qt Mobility mwts network Qt Bearer in Qt5 Qt Qt mwts systeminfo qt 3 Not packaged In Qt5 Qt Qt Qt Qt Mobility mwts qtmultimedia qt qt mobility 17 Not packaged In Qt5 Recording image viewing FM

    Original URL path: https://wiki.merproject.org/wiki/Quality/Test_coverage (2016-02-01)
    Open archived version from archive

  • Quality/Metrics - Mer Wiki
    from releases changelogs Open bugs and tasks Product Mer Core Status NEEDINFO UNCONFIRMED NEW ASSIGNED TRIAGEDUPSTREAM REOPENED By priority By severity High 15 Critical 2 Normal 44 Major 4 Low 93 Normal 51 Undecided 8 Trivial 2 Echancement 4 Task 96 Total 160 64 bugs and 96 tasks Closed bugs Product Mer Core Status RESOLVED RELEASED VERIFIED CLOSED By resolution By priority Fixed 164 High 39 Duplicate 7 Normal 48 Invalid 4 Low 43 Code available 2 Undecided 47 By Assignee Sage 77 Stskeeps 26 need triage 15 not taken 10 Antti Alatarvas 6 lbt 6 siteshwar 6 letters random13 4 izero79 4 arnaud 3 Martin Brook 2 Robin 2 denis 2 p vuorela 2 Risto Avila 2 Seppo Yliklaavu 2 Benjamin Federau 1 ajalkane 1 Lauri Kaila 1 shalx99 1 Tanu Kaskinen 1 Vas Gurevich 1 vdv100 1 Total 177 74 bugs and 103 tasks Mean time of fixing bugs tasks days Product Mer Core Status RESOLVED RELEASED VERIFIED CLOSED Priority Mean time Min Max Bugs High 57 6 0 3 202 1 Normal 66 1 2 7 203 6 Low 166 4 122 2 202 2 Undecided 38 1 0 0 239 9 Tasks High 57 5 11

    Original URL path: https://wiki.merproject.org/wiki/Quality/Metrics (2016-02-01)
    Open archived version from archive

  • Quality/Development - Mer Wiki
    to opt tests packagename audio video image text etc OBS Host SDK and device side tools to mer tools devel Once package is tested and you are happy with it create submit request to mer tools testing Please contact lbt from freenode IRC if you have questions Normally tests are packaged in the same repository than actual test target but if you have independent test software those should locate at mer qa GIT repository Repositories are webhooked to mer qa devel OBS project Please contact mkosola or kontio from freenode IRC nemomobile to create git repos and wehooks to OBS Test development As a developer Search or ask the test s version control location Pull the test s source code and make changes Copy the original package to your home project in OBS Update your changes to the OBS Test your changes Push your changes to the version control Inform QA team about the changes with changes diff URL to gitorious gerrit github diff The QA team will review retest and update the tool to OBS The QA team will select and approve tests for package and release testing As a QA team member Review and test submitted changed test

    Original URL path: https://wiki.merproject.org/wiki/Quality/Development (2016-02-01)
    Open archived version from archive

  • Quality/Terminology - Mer Wiki
    Mer repositories are in good shape so that decisions can be made if the software is ready for further testing or release Of course the release decision cannot be made only based on sanity test results further testing results will also be referred to Test package Test packaging is the mechanism to wrap any tests in rpm packages for manual and automatic executions contain all tests scripts and configuration files required to run tests define dependencies the ones it tests the test tools and test data it depends on if any contain test plan located at usr share packagename tests tests xml Test plan A test plan is a XML file that defines test cases and test case s properties Test plan can include tests for multiple domain areas and or test types Test case Low level Test case A test case with concrete implementation level values for input data and expected results High level test case a k a test idea A test case without concrete implementation level values for input data and expected results Logical operators are used instances of the actual values are not yet defined and or available Test case verdict QA verdict definition Pass A test is deemed to pass if its actual result matches its expected result Fail A test is deemed to fail if its actual result does not match its expected result N A Not Applicable can be seen as a initial value which is left as a verdict for a test case when no other verdict cannot be given due to some reason e g feature is not implemented yet test case could not be executed due to failure in test infra etc For all Fail verdicts it would be preferable that bug ID is given For all N A verdicts

    Original URL path: https://wiki.merproject.org/wiki/Quality/Terminology (2016-02-01)
    Open archived version from archive