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