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 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
