On 15/12/10 21:49, Bernd Stramm wrote:
On Wed, 1 Dec 2010 14:33:29 +0000
Andrew Flegg<[email protected]> wrote:
On Wed, Dec 1, 2010 at 13:23, Alberto Mardegan
<[email protected]> 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..."
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
