openupgrade-drivers team mailing list archive

[Pedro Manuel Baeza Romero <pedro.baeza@xxxxxxxxx>]

+1 to both suggestions. It must be a multi-valued field as Stefan says, but
it's a very good improvement, because now we have a desynchronization
between real work and documentation.

Regards.


2014-04-04 10:17 GMT+02:00 Stefan Rijnhart <stefan@xxxxxxxx>:

>  On 04/04/2014 09:52 AM, Holger Brunn wrote:
> > how about a flag in the module manifest that tells the OpenUpgrade
> > server that a module is fit for migration (either because there's
> > nothing to do or because the migration script is ready)?
> >
>
> >
> > What do you think?
> >
>
> Holger,
>
> +10
>
>
> > And what about the flag's name? 'migrated': True ?
> >
>
> We now have various statuses in the docs: none, done, nothing to do, no
> changes. Maybe make it a field 'openupgrade_coverage' (or just 'coverage')
> with selection
>
>     'unknown' (default), 'partial', 'full', 'nochange'
>
> We could use 'nochange' for both current statuses 'nothing to do' and 'no
> changes', with meaning 'no changes in the module to warrant a migration
> script' to cover both cases. When autogenerating the module coverage list
> for the official addons, 'unknown' would translate to 'todo'. At migration
> time, the error log could clarify that if an official module has status
> 'unknown', this would usually mean that the migration can not be considered
> succesful.
>
> Should we move the user notes to the manifest as well to have them logged
> at the end of the upgrade, so that we finally have a usable report for
> post-migration administrative work that is signalled in these notes?
>
> Cheers,
> Stefan.
>
>
> --
> Mailing list: https://launchpad.net/~openupgrade-drivers
> Post to     : openupgrade-drivers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openupgrade-drivers
> More help   : https://help.launchpad.net/ListHelp
>
>