[meego-packaging] MeeGo Package Versioning (was Re: MeeGo package SR procedure)

[Patrick Ohly]

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 <jean-luc.lamadon at nokia.com> 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 <ext-maitrey.mishra at nokia.com> 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.