openerp-community team mailing list archive

[Houssine BAKKALI <houssine.bakkali@xxxxxxxxx>]

+1

Yes conflicts between module could be registered as a bug... But meanwhile
it's already too late for production environnent and complicate and time
consuming on dev/delivery context to investigate why it's bugging. It costs
money and generate delay on project development. Anyway this kind of
experimentation, try and error, install and pray should be done in a R&D or
Labs context not on a project/solution implementation basis.

Knowing conflicts between modules give us information to estimate solving
the conflicts if we plan to use it for customers. Seaching and solving the
issue could hence be budgeted in the project delivery/implementation and
then be giving back to the community.

Making a bug report is time consuming, not covered by the support contract,
and could land in the whishlist or anything else... plus the fact that if
tackled it could take several months before to land on stable branch.

So having this info give a real added value and doesn't avoid filling a bug
report anyway.

my two cents.

Houssine


2013/8/19 Alexandre Fayolle <alexandre.fayolle@xxxxxxxxxxxxxx>

>  +1, I still feel this is needed.
>
> Fabien : I've seen at least one re-implementation of MRP in the wild,
> which are obviously not compatible with the official mrp addon. Just having
> a comment in the description of the module is not enough : we need
> something stronger which prevents accidental installation of a known
> incompatible module.
>
> Same thing for customer specific modules : if I'm forced to completely
> rewrite a API function (e.g. it lacks an extension point) without calling
> the super() implementation of that method, I generally won't fix this in
> all the standard addons which reimplement that method (and call the super()
> implemenation), if they are not installed on the customer's instance.
> However, having a quick way to tell that such modules are incompatible with
> the specific one I'm installing will ease the work of maintainance as they
> will know something has to be done before one such new module is installed
> during the application lifecycle.
>
> --
> Alexandre
>
>
>
> On 17/08/2013 16:03, Fabien Pinckaers wrote:
>
> Hi,
>
>    Some community modules are incompatible with each other, or with core
> modules. It may not be desirable but it is sometimes unavoidable and is a
> fact today.
>
>
>  Do you have some examples of incompatible modules where it's unavoidable?
>
>  My first though would be to understand why a module may create
> incompatibilities and fix what could be fixed. (e.g. on_change stuff may
> create incompatibilities, but it's fixed with the new API)
>
>  Developing a module that create incompatibilities is usually the sign of
> a bug (e.g. a module that add a required field without a default value ->
> this creates incompatibilities but it's a bug as they are plenty of others
> way to trigger the bug)
>
>  I have only one reason in mind where incompatibilities are created and
> it's not a bug; modules embedding JS libs that are incompatible. It's not a
> bug but it's avoidable.
>
>    Discovering such incompatibilities is a painful process, and there is
> no structured mechanism to communicate about them once they have been
> (re)discovered.
>
> This has been discussed in the past [1], but was not followed by concrete
> steps, AFAIK.
>
>  As a first step, would the community agree with the addition of a field
> named "incompatible" in __openerp__.py, providing a simple list of module
> names that are known to be incompatible?
>
>  This would be beneficial to the community, even without support in the
> core or apps.openerp.com, by letting module maintainers declare known
> incompatibilities.
>
>  Populating this field can follow the normal merge proposal and review
> process.
>
> If it gains traction, tooling may support it in a second step.
>
>
>  Looks like a good approach as the biggest risk is that those extra
> fields are not maintained.
>
>  Another way is to consider incompatibilities as bugs. (as per my comment
> above) So, anyone can easily fill a bug on a branch he doesn't own, it's
> way easier than going through the merge proposal process. (and all the
> issues related to a module are visible in the same list of bugs)
>
>   Note that I consciously avoid the topic of version dependencies as this
> would open a bigger can of worms.
>
>
>
>
>
>   The only purpose of the present proposal is to provide a human and
> machine readable way to document partitions in the addons landscape.
>
>  Cheers,
>
> -sbi
>
>  [1] https://lists.launchpad.net/openerp-expert-framework/msg00840.html
>
>   Stéphane Bidoul | @SBidoul <https://twitter.com/SBidoul>
>  Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120
>
>
>
>   _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> Alexandre Fayolle
> Chef de Projet
> Tel : + 33 (0)4 79 26 57 94
>
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac Cedexhttp://www.camptocamp.com
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>