On Mo, 2010-12-06 at 12:58 +0000, David Greaves wrote: > On 03/12/10 20:41, Selbak, Rolla N wrote: > > So to answer your q, you're right, the SR# bug comment is not necessary > > right now, but a nice-to-have for ease of tracking. > > > > The one thing you are required to do is make sure the bug or feature you are > > requesting is set to 'resolved', which indicates that the code is submitted. > > Then once it hits MeeGo Trunk, Release Engineers will set the bug to > > 'released', or if the submisison is rejected, they will set the bug to > > 'reopened'. > > I am still concerned that MeeGo cannot easily (historically) determine which > rpm > or release a bug is fixed in. This is especially problematic on a > week-to-week > basis and it matters more to our customers (device vendors) than to MeeGo > core > engineering - which is why > a) it is important > b) we don't really see it - so we don't care
It also matters to our own development. Another example is the recent Tracker update where "--enable-maemo" was removed, which broke contact storage on MeeGo (qtcontacts-tracker depends on Maemo ontologies): * Sat Nov 27 2010 Jean-Luc Lamadon <[email protected]> 0.9.26 - Qtcontacts-tracker needs update (BMC#10290) - Added patches 0006 and 0007 to set configuration option --enable-maemo * Thu Nov 25 2010 Mishra Maitrey <[email protected]> 0.9.26 - BMC#10287 - Removed --enable-gstreamer-tagreadbin form the ConfigOptions [more comments on 0.9.26 removed] As you said, it's impossible to tell from the change log or from BMC #10290 which rpms were affected, and that has caused confusion. So I second your proposal to do something about this problem. If possible, also address bug tracking on maintenance branches, instead of introducing just another incomplete solution. Having a bug in "RELEASED" and then "VERIFIED" state does not mean that it has been fixed in all of MeeGo. The current approach of dealing with this (cloning bugs) causes more confusion than it helps (IMHO...). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
