openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 10/23/2012 11:54 AM, Alexandre Fayolle wrote:
> 
> I fully understand what kind of pressure you are under about the 7.0 
> release. Integrators are also under pressure, as new projects cannot 
> really start with a 6.1 target as the support will end very soon. So we 
> have to consider porting the existing body of addons that we routinely 
> install on customer instances before the release notes are available.

The release notes (at least a draft version) will be available before the final
release, we're trying to get them out as soon as possible.


> I merely thought you had some porting directives you used for the major 
> changes arriving in 7.0 which you could share. As a developper / 
> project manager, I don't need a shiny document. Maybe this is a process 
> evolution you could consider for future releases. Linking changes to 
> blueprint documents would considerably ease the writing of the release 
> notes, and allow partners to follow the development of trunk, in a way 
> which is much easier than guessing the intents by eyeballing diffs, and 
> figuring out fundamental (schema-level) changes and cosmetic ones 
> (views). Of course, this eyeballing will still be necessary in the very 
> end.
> 
> In the company I worked at before, all changes other than refactorings 
> had to be linked to a "ticket" in the tracker (feature request or 
> evolution request). In the end, when a new version was released, it was 
> very easy to get a list of new features and changes by listing the 
> tickets that were closed by the release. Of course this did not mean 
> that the porting method of plugins from one version to another was 
> easy, but at least it meant that you could check your plugins against a 
> list of changes.

Sure, and we're closer to this than you might think, as almost each commit line
is already linked to a rationale: most changes in trunk (addons|server) land by
merging a "feature" or a "bugfix" branch. This is quite different from what
happened one or two releases ago (ask your new colleagues about it ;-))
For a bugfix merge the rationale is described in the merge comment and the bug
history. For a feature merge, the rationale is normally written down in the
kanban task of our R&D pipeline, which is not public at the moment.
(Yes we hate LP blueprints, don't even ask :P)

We've been looking for a way to make the pipeline public for a while now, but
it's still too informal - a lot of communication happens out-of-band/orally,
and the task descriptions are always quite technical/partial - hardly useful
for anyone that does not sit with our R&D teams.
It's of course used to write the release notes (and the many blog posts about
new features that have been posted in 2012)

As usual, it's all about time and resources... we're not oblivious to all best
practices ;-) So please be patient, everything is still changing and improving
daily.