[MeeGo-dev] New keyword in Bugzilla for N950 device
Hi all, Since N950 devices are already in use and there's no option to select multiple devices for a new bug, I have added keyword N950. When found a new bug with N950 please add the 'N950' keyword - IF the bug is found with N900 Community edition, add also 'N900CE' keyword - IF the bug is only for CE, please use prefix [CE] in the beginning of the bug summary. - IF the bug is found in the N900 and N950 devices, after you have filed the bug, please select from the (HW) Platform dropdown menu option: 'N900' This is little bit complicated, I know. But giving the following information are very valuable for the Community Edition development team. --- Iekku Pylkkä MeeGo Computers Core System Testing / Error manager +358 40 749 0894 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-handset] N900 and N900CE related bugs
Hi, You have good point there. It has been agreed that bugs reproduced/reported only for N900CE can be verified after fix. If the bug is reproduced with the Vanilla image also, it can be verified for N900CE = add comment, remove the keyword N900CE. The bug can stay as a resolved fixed, but can't be verified before the fix is released for Vanilla image. Little bit complex, but it was the best way to handle the situation. I need to check if this is commented clear enough in the N900 wiki, need to check and if not, I will add the information there. Thanks, Iekku -Original Message- From: meego-handset-boun...@lists.meego.com [mailto:meego-handset- boun...@lists.meego.com] On Behalf Of ext Luis Araujo Sent: 17 August, 2011 04:45 To: meego-dev@meego.com Cc: meego-hand...@lists.meego.com Subject: [Meego-handset] N900 and N900CE related bugs Hello, A N900 bug should be resolved as fixed if such a bug is fixed for the N900CE version? I have seen some bugs following this trend, and I am not sure if this is what we want, or if this was discussed somewhere, do we have a consensus about how to go in such a situation where one bug is fixed in one version but not in other? In my opinion a N900 bug should stay open as long as it is reproduced in the vanilla images, or, if Release Managers decide to mark as INVALID or WONTFIX for such a version. Now, I agree that a N900 bug could be used to track N900CE issues too, but closing a bug reported for one image version, because it is fixed in another image version is a bit confusing in my opinion, even if it is platform related. Comments?, I am not sure if this is explained somewhere, but it'd be nice if we could get a consensus about this if there is none yet. Regards, ___ MeeGo-handset mailing list meego-hand...@lists.meego.com http://lists.meego.com/listinfo/meego-handset ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-handset] N900 and N900CE related bugs
Hi, We had nice conversation about this at IRC yesterday with Luis and Gary Birkett (lcuk) and I promised to send a short description via mailing list. The main problem is that CE and Vanilla aren't in sync and CE fixes doesn't work in Vanilla. This may lead to following: Bug reported with Vanilla image: - Might be ignored / marked as a duplicate for a bug existing in the CE. - If bug is fixed for CE, the bug is verified, but the fix is missing from Vanilla. Bug reported with CE image, reproduced with Vanilla: - Fixed and verified for the CE, Vanilla is ignored. So, we need to avoid these. But how? This might happen with other devices also, same hardware but different release, so let's try to find a good method to use not only with N900 but others to come also. One solution is to Clone the bug: - If reported for Vanilla and then reproduced with CE, the CE gets own clone bug and vice versa. - Fixing, releasing and verifying is done separately to both. And the bugs are still linked in a comment level, so nothing important isn't disappearing. One solution is to do as Luis proposed. - Problem: there isn't clear visibility in the bug if it's fixed for the image it has been reproduced later - Problem: if the bug is fixed for the image it's originally reported, but not to the other One solution is keep conversation ongoing in one bug and clone it IF needed - IF the bug is fixed with original image, then bug is cloned for the other image - If the bug is fixed for the image where it has been reproduced later, commenting that this is fixed and keep the bug open to show that originally reported bug isn't fixed/released - Problem: there isn't clear visibility in the bug if it's fixed for the image it has been reproduced later Best solution: - You name it. It must be one when all of us are happy (or at least somehow satisfied) : developers, testers, users, managers. I hope I could add everything needed to this bug. Please be active and tell what you think. Br, Iekku -Original Message- From: ext Luis Araujo [mailto:luis.ara...@collabora.co.uk] Sent: 18 August, 2011 03:55 To: Pylkka Iekku (EXT-Ixonos/Tampere) Cc: meego-dev@meego.com; meego-hand...@lists.meego.com Subject: Re: [Meego-handset] N900 and N900CE related bugs Hello Iekku, Let me summarise and see if I get this right: (*) Bugs reported for N900CE (or other derivatives) that are fixed but still reproduced in N900 Vanilla images: - Set status to RESOLVED/FIXED - Remove N900CE keyword - Add comment that it is verified for N900CE (It could be useful to add a comment stating that it is still reproduced in Vanilla image too) - Set status to VERIFIED only once the fix arrives to Vanilla image. The current procedures goes like that?, if I follow you right?, This sounds good for me. Now, my main concern and I also propose here a way to handle such a case is the following: (*) Bugs reported for N900 Vanilla images but the fix is _only_ available so far for N900CE or other derivatives: - Stay bug status as open (NEW, REOPENED...): This has some benefits in my opinion, for example, it avoids duplicating bugs, users testing in the Vanilla images will find this bug report and also add any comment if needed. - Once there is a fix for N900CE or other derivatives: Add a comment with the upstream merge or OBS submit request of such a fix. This way, Vanilla users finding this bug will find the fix is already available for one of the derivatives and they can just start using that instead if they want (hey ... project promotion through bug reporting :P) - Only set RESOLVED the bug once a specific decision or fix has been applied to this Vanilla image: a) Bug fixed: set RESOLVED/FIXED and VERIFIED later. b) Bug won't be fixed for N900 Vanilla image for X or Y reason (it is not always easy to know who takes this decision, Release Managers?, if RM are not sure, upstream developers could have a call here): the status is set to INVALID or WONTFIX, probably adding a comment stating the reasons. I see two main and important advantages of this approach: - Users of the image will still be able to find a bug report for the reproduced issue, hence avoiding duplicating bugs. - Users will be able to find where the fix is already available. This whole thing is probably a bit complex, like you said Iekku, but it'd be nice to make this clear so we can take full advantage of bug reporting for all these different image derivatives, we could come out with some guidelines not only for N900 platforms, but also any other ones. Hopefully this thread might help to clarify or set some of these guidelines :) , I would be glad to add this to the wiki if you think it is good enough. Please, comments, suggestions? Regards, - Luis On 08/17/2011 01:36 AM, ext-iekku.pyl...@nokia.com wrote: Hi, You have good point there. It has been agreed that bugs reproduced/reported only for N900CE can be verified after fix. If the bug is reproduced with
Re: [MeeGo-dev] [Meego-handset] Changes in the MeeGo Bugzilla for Handset User Experience
Hi all, Want to remind about the changes. I haven't received any comments about the adding other UX stuff to Handset UX. See all the conversation from: http://lists.meego.com/pipermail/meego-handset/2011-July/thread.html Shane Bryan replied for the original proposal and libseaside is staying as it is. Any other comments? Br, Iekku From: meego-handset-boun...@lists.meego.com [mailto:meego-handset-boun...@lists.meego.com] On Behalf Of ext ext-iekku.huttu...@nokia.com Sent: 12 July, 2011 12:08 To: meego...@lists.meego.com; meego-hand...@lists.meego.com; meego-relea...@lists.meego.com; meego-dev@meego.com Subject: [Meego-handset] Changes in the MeeGo Bugzilla for Handset User Experience Hi all, There's going to be some changes in the MeeGo Bugzilla Handset User Experience. Back ground for the changes: Handset UX isn't fully maintained and currently there's no activities for 1.3. N900 CE project is only who is maintaining / developing anything to Handset UX and when bugs are fixed in CE the fixes are also available to add to the MeeGo release. For more information about the N900CE, please visit: http://wiki.meego.com/ARM/N900 Since N900 CE is maintaining it makes sense to change the default assignee and QA contact for a people who are actually working with the maintenance/development. And since some parts aren't currently maintained, the bugs are going to be closed as wontfix. By that we don't lose any information and if someone is willing to make patches/fixes, they can do that, even if bug is marked as a wontfix. Please, feel free to take a look :) There's still components without default assignee (question marks in the name or instead of the name), if you are willing to take the action, contact me. I'm going to wait 2 workdays to get the feedback before doing the changes, any comments and ideas are welcome. Bugzilla components, and the coming changes: Applets: Doesn't exist in the Handset, all bugs going to be closed as a wontfix. After that requesting to delete the component. Audio Player: Is in use at CE, most critical bugs are fixed. Default assignee: ??, QA contact: iekku? Calendar: CE is using the Tablet UX calendar -- all bugs are going to be closed as wontfix Camera Application: in active development, new default assignee: Joonas Taskinen, new QA contact: Srikanth Connectivity UI: component itself is useless, since the whole Connectivity UI is part of Settings (or part of System UI), current bugs are going to be moved under correct component and after the moving requesting to delete the component. Contacts: in use and under maintenance Default assignee: tswindell?, QA contact: Srikanth Dialer: stays as it is DuiHome: Name will be changes to MeegoTouchHome. Default assignee mirek, QA contact: Srikanth Email client: not in use, every bug is going to be closed as wontfix. Generic: default assignee will be changed to Marko Saukko Instant Messaging: Not in use at CE -- all bugs are going to be closed as wontfix libseaside: is in use. Default assignee: ??, QA contact: ?? Package Manager UI: stays as it is Photo Viewer: is in use and maintaining is ongoing. Default assignee: alexandr.ivanov/ daniil.chuiko?? and Default QA contact Srikanth Settings: is in use and maintaining is ongoing. Default assignee will be gabor and Default QA contact Srikanth SMS: stays as it is Social Networking: Not in use at CE -- all bugs are going to be closed as wontfix Status menu: bugs are going to move to System UI and after that requesting to delete the component. Sync UI: Not in use at CE -- all bugs are going to be closed as wontfix System UI: Is in use, Default QA contact will be changed to Srikanth Theme: Is in use and Default assignee will be mirek and Default QA Srikanth UI infrastructure: all bugs are moved to OS Base - libmeegotouch, after that requesting to delete the component. UX stability: all bugs are moved to OS Base - libmeegotouch, after that requesting to delete the component. Video Player: in use and under maintenance Default assignee: ??, QA contact: iekku? Web Browser: stays as it is Window Management: Default assignee is changed to mirek About the current bugs: * All NOT ARM related bugs are going to be directly WONTFIX, cause no official support / maintenance currently for IA. Br, Iekku Huttunen MeeGo Computers Core System Testing / Error manager +358 40 749 0894 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-qa] MeeGo Distribution Packages - product in the Bugzilla
Hi, Thanks Luis for your activity. You have been marked as a default assignee for the components you listed below. Br, Iekku From: ext Luis Araujo [mailto:luis.ara...@collabora.co.uk] Sent: 01 September, 2011 21:08 To: Pylkka Iekku (EXT-Ixonos/Tampere) Cc: meego-hand...@lists.meego.com; meego...@lists.meego.com; meego-dev@meego.com Subject: Re: [Meego-qa] MeeGo Distribution Packages - product in the Bugzilla On 09/01/2011 01:14 AM, ext-iekku.pyl...@nokia.commailto:ext-iekku.pyl...@nokia.com wrote: Hi, Here's quote from the mail about the changes in the Bugzilla's Hanset UX. On Wed, 2011-08-31 at 07:06 -0700, Arjan van de Ven wrote: I'm ignoring meego bugzilla as useless unless it has a 1:1 mapping between packages and components That mapping has been in place for a while. Check Classification = MeeGo Platform Product = MeeGo Distribution Packages. Andre I started to wonder how many knows about the Bugzilla Product for MeeGo Distribution Packages. The product is not in so wide use as I was expecting, maybe because it's meant for the MeeGo 1.3. I hope it's going to be in use later on. I notices also that none of the components have QA-contact. This needs to be fixed. I found out also that all components doesn't have default assignee. That needs to be fixed also. Following component are having default assignee 'need-maintainer @meego.bugs'. Sorry, I know this list is very long, but the components are in the alphabetical order with short description: meegotouch-feedback MeeGo Touch feedback infrastructure meegotouch-feedbackreactionmaps MeeGo Touch Feedback ReactionMaps Plugin meegotouch-inputmethodbridgesMeego Input Method Client IMContext for GTK and CLUTTER meegotouch-inputmethodengine Meego UI Input Method Engine meegotouch-inputmethodframework MeeGo UI Input Method Framework meegotouch-inputmethodkeyboard MeeGo Virtual Keyboard Not sure what it is the procedure to request assignee for these packages, but I let you know here that you can make me default assignee for these meegotouch-* packages. Regards, ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] N900 Hardware adaptation component moved in BMC
Hi, We have moved the Nokia N900 Hardware adaptation Product as a Nokia N900 component under to: MeeGo Platform Hardware Adaptation. All existing bugs in the old Nokia N900 Hardware adaptation product are moved to the new component. The old product is going to be deleted, so please start to use the new component. Other news: Handset UX changes are starting today, I will inform more during the changes if needed and let you know after the changes have taken the place. --- Iekku Pylkkä MeeGo Computers Core System Testing / Error manager +358 40 749 0894 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Update BMC default MeeGo Release fields value from 1.2 to 1.3?
Hi, As the time goes by and the new MeeGo Releases are coming, I would like to update the MeeGo Bugzilla's 'MeeGo Release' field's default value for new bugs from 1.2 to 1.3. Any opinions? Are there some Platforms which aren't yet ready for the change? This field's default value is global, so it's important to know if this can be done now. --- Iekku Pylkkä MeeGo Computers Core System Testing / Error manager +358 40 749 0894 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, Sounds great! Count me in. -- Iekku -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev- boun...@meego.com] On Behalf Of ext Carsten Munk Sent: 03 October, 2011 09:01 To: meego-dev; meego-comm...@meego.com Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. A lot of proposals have been put forward: * Move to Tizen and trust that They'll get it right this time * Merge or join some existing projects (like the Qt Project, Debian, openSUSE, etc) * Keep MeeGo alive by approaching the Linux Foundation The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: How does the concept of a truly open and inclusive integration community for devices sound? After all if upstream is king - then contributions will end up the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE. Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next. To make it clear: this is not in any way an anti-Tizen or anti-Intel project, but a direction we can and will go in - we strongly want to collaborate with Tizen and Intel. We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device. We decided to approach the problems and potential scenarios of change in MeeGo in the light of the reallocation of resources caused by what is now known as the Tizen work. There have not been any Trunk/1.3 releases since August and Tablet UX has totally stalled. What really works (and works quite well) is the Core. It's time to take the pieces and use them for reconstruction. We have some clear goals: * To be openly developed and openly governed as a meritocracy * That primary customers of the platform are device vendors - not end-users. * To provide a device manufacturer oriented structure, processes and tools: make life easy for them * To have a device oriented architecture * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5) * To innovate in the mobile OS space Now we'd like to talk a bit about what specific initiatives we propose to take: 0) Becoming MeeGo 2.0 Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e. supporting HTML5/WAC and the application story there and feed back to that ecosystem. 1) Modularity. A set of architectural components for making devices. Rather than dictate the architecture we will support collaboration and the flexibility to easily access off-the-shelf components for device projects. Component independence permits focused feature and delivery management too. Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core. 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building products with. We have already taken MeeGo and cut it into a set of 302 source packages that can boot into a Qt UI along with standard MeeGo stack pieces. This work can be seen already at [2] and we've made our first release and have had it booting on devices already[6]. To ease maintenance, we would like to encourage people to participate in the Core work of the Tizen project, utilizing their work where we can in Mer: why do the same work twice? Even if Tizen turns out to be dramatically different, the maintenance load of 302 source packages - much of it typical Linux software, is significantly lower than that of the 1400 packages found in MeeGo today. Using another lesson learned from MeeGo, we also want to port this work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc - allowing much more freedom for porting to new devices. 3) Change governance towards a more technically oriented one, similar to the Yocto Project We'd like to propose a revamp of governance based upon the Yocto Project governance - which is much more geared towards open technical work - encouraging collaboration and discussion. You can look at a description of this at [3]. 4) Work towards better vendor relations and software to
Re: [MeeGo-dev] will Mer support application developers?
Hi, Yesterday we had already MeeGo Community Edition running on top of Mer, maybe CE is the answer you are looking for? -- Iekku From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Vim Toutenhoofd Sent: 04 October, 2011 05:18 To: meego-dev@meego.com Subject: [MeeGo-dev] will Mer support application developers? Carsten, you wrote: ... [snip] ... to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: ...[snip]... On Mer's websitehttp://merproject.org/ I found that one of its goals is: That the primary customers of the platform are device vendors - not end-users. What do you see as Mer's goals relative to application developers who may be looking, for instance, for access to a device's sensors? Are application developers considered end-users? Vim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
