On 1 Jun 2011, at 00:42, Carsten Munk wrote: > 2011/5/31 David Greaves <[email protected]>: >> So now 1.2 is out I'd like to re-raise the 'changelog version' issue, ie: >> >> MeeGo package versions are not stored in the MeeGo changelogs (only upstream >> baseline versions). >> Information about a package version is primarily communicated via the >> changelog. >> The current policy does not accurately link the package/rpm version to the >> changelog entry. >> >> Given a changelog snippet it is not possible to determine which weekly >> release a bug is fixed in >> >> I pushed a potential technical solution into OBS some time ago: >> https://bugs.meego.com/show_bug.cgi?id=10910 >> >> This allows the prjconf to specify >> Release: <SPEC_REL>.<CI_CNT>.<B_CNT> >> >> This means that the value provided in the specfile is used where <SPEC_REL> >> is defined instead of being ignored. >> >> It would also make sense to have automation rules to verify this as part of >> the SR process - this can be done easily with BOSS. > > (argh top posting) > > So, we now have BOSS in the build.meego.com system. What stops us from > exporting delta meta data that includes delta of changelogs in > machine-readable form from previous version in places like > http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.0.20110517.1/builddata/ > ? > > In such a way that we collect data on in which release package changes > were made. > > IE, a file containing that "in this release, we changed package source > versions from X to Y" > > Our atomic recrd of a package release should be what is released on > repo.meego.com, IMHO. So we can pinpoint that "last change to source > package was in MeeGo release X.Y.Z", effectively tying the records > together. >
isn't this already happening here: http://repo.meego.com/MeeGo/snapshots/stable/1.2.80/1.2.80.2.20110516.2/builddata/reports/ ? Anas > Can you maybe specify some exact use cases we can help analyze? > > BR > Carsten Munk > >> >> David >> >> On 06/12/10 13:18, Patrick Ohly wrote: >>> >>> On Mo, 2010-12-06 at 12:58 +0000, David Greaves wrote: >>>> >>>> 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. >> >> <snip comments about bug lifecycle> >> >> >> >> _______________________________________________ >> MeeGo-packaging mailing list >> [email protected] >> http://lists.meego.com/listinfo/meego-packaging >> > _______________________________________________ > MeeGo-packaging mailing list > [email protected] > http://lists.meego.com/listinfo/meego-packaging _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
