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? > > Certainly part of the problem is that good release management, > changelogs etc. aren't necessarily compatible with weekly release > cycles and tracking versions. > > 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. > > > 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." > > Ultimately, everything's being done for *some* reason on MeeGo. Why does the reason for a new release have to be in MeeGo? 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. > Perhaps a placeholder issue (per release/milestone) for some rapidly > developing library which is primarily targetting MeeGo would be > sufficient? For example, it could be a feature of the form "Provide a > mechanism for applications to start quickly" which is met my > *multiple* changes to applauncherd. > > Cheers, > > Andrew > -- Bernd Stramm [email protected] _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
