[meego-packaging] Changelog must refer to a feature # or bug #

[David Greaves]

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.

Agreed.

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

Not really.

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

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.

David

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."