[meego-packaging] Changelog must refer to a feature # or bug #
david at dgreaves.com
Thu Dec 16 10:58:24 PST 2010
On 15/12/10 21:49, Bernd Stramm wrote:
> On Wed, 1 Dec 2010 14:33:29 +0000
> Andrew Flegg<andrew at bleb.org> wrote:
>> On Wed, Dec 1, 2010 at 13:23, Alberto Mardegan
>> <mardy at users.sourceforge.net> wrote:
>>> Developer releases liblib 1.0, and that gets packaged into Meego.
>>> Then he refactors it so that all methods are twice as fast. We
>>> writes "All methods are twice as fast" in the commit message of the
>>> SVC repository, then he packages it for MeeGo and writes the same
>>> comment in the .changes file. Isn't that good enough information?
>>> Why do we want to force him to go through the extra burden of
>>> creating a bug or feature request?
Good enough for what? Who (and what) are changelogs and the text in them for?
Especially in MeeGo's case.
I think they should:
* identify which bugs are fixed
* identify which features have been worked on (although not necessarily finalised)
* communicate to others
(there's a small issue that the changelog doesn't include the version ... but
that's for another email .... )
>> It boils down to auditability and reasoning, IME. In your case of
>> liblib, the methods should, ideally, be refactored under a public
>> issue tracking item (possibly called "Performance") which would list
>> all the problems faced etc.
>> For liblib's new version to be included in MeeGo though, experience
>> would suggest there'd be a bug on bugs.meego.com called "Update liblib
>> to 1.x" with the description describing the benefits this gives to the
>> MeeGo stack; the verification that it hasn't broken any of the
>> Compliance guarantees; the version in which it will be included etc.
I'd also see some packages being given a feature# "Track upstream".
Not all packages get this though - eg gstreamer doesn't get a free pass to just
blindly upgrade to a new upstream release - it's so fundamental that an
architect should really agree such a move under a specific bug.
>>> What about rewording the criteria like this:
>>> "The .changes file must clearly describe the new features, bugfixes
>>> and improvements, and contain references to all the MeeGo.com bugs
>>> and features addressed, if any."
One very important thing - we're trying to distribute and automate the
integration burden. At the moment we have a bottleneck which could do with
The objective of "Changelog must refer to a feature # or bug #" is *not* to
"make you write a bug".
It is to allow us to quickly reject changes that don't reference a bug/feature
and as Andrew says, to communicate specific issues.
Ideally it should also allow QA to verify that bugs are closed and inform people
that features are being addressed.
>> Ultimately, everything's being done for *some* reason on MeeGo.
> Why does the reason for a new release have to be in MeeGo?
Some packages may require this, some may not.
> There are plenty of reasons that a produce (lib or app or something
> else) is updated from upstream, that is unrelated to anything MeeGo.
> In such cases, the reason would be documented somewhere upstream.
I don't think that the changelog is asking for *every* change to be justified -
and the case you cite (a change simply to import a new upstream) is easily handled.
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
More information about the MeeGo-packaging