On 01/06/11 15:46, Anas Nashif wrote:
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
<snip>
(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/
?
You could ... but I'd say changelogs are machine readable and are the
canonical form of expressing deltas against versions.
What we have now is a .changes file that is MeeGo specific and yetdoes
not map to a MeeGo-specific version - I appreciate that it made sense to
try this approach but I don't think it offers enough benefits for the
problems it causes.
So I'd counter with "why can't we use the widely used and proven method
of including the full version identifier in each changelog entry?"
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/
?
Yes.
And as a vendor Nokia had REVS. It was designed so that every time a
commit is made into Trunk it looks at the authoritative information (the
changelog) and puts it in a DB. It also takes every
image/release/snapshot and puts all those changelog entries into the DB
(again, it does the 'right thing' and uses the changelog as the master
data source).
Can you maybe specify some exact use cases we can help analyze?
The bug and original emails that I top-posted on had some.
Essentially I would like a *guarantee* that when I look at a changelog I
know exactly which rpm versions includes each of the changes mentioned.
David
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
