Contributors mailing list archives
Re: OCA Code sprint: sprint topicsby
Vauxoo, Moisés López Calderón
"MQT py3 supports" could be a good matter since that odoo 11 will be use python3
2017-09-28 12:16 GMT+02:00 Graeme Gellatly <email@example.com>:
Yannick,Maybe I'm not getting you. Even with an empty repo, a port of a module, whether it is in repo, or across repos would still bring across all the history if done correctly. I can't see how its any different to not starting with an empty repo for this particular case.On Thu, Sep 28, 2017 at 11:02 PM, Yannick Vaucher <yannick.vaucher@camptocamp.
com> wrote:>> (I see about 10 cases in 10.0 for a total of 400 modules).Well, 10 for version 10.0 but don't forget all the renaming split/merges in previous versions. I think it's valuable to still be able to track what was the name of a module 3 versions earlier and what the changes are. I don't think most project migrate each versions. It's more often a 2 or 3 versions jump.On 28 September 2017 at 11:16, Pedro M. Baeza (Tecnativa) <firstname.lastname@example.org> wrote:Yannick, at the end, a module that has been renamed, keeps its previous history on older branches, so that's not a problem at all. It's also a very infrequent case (I see about 10 cases in 10.0 for a total of 400 modules).As stated also, the workflow will be the same, emptying the branch or not: you will have to import the same missing commits, but this time the missing commits wil be all ;)Regards.2017-09-28 11:02 GMT+02:00 Yannick Vaucher <email@example.com m>:Sorry to come late on the sub topic of emptying the new branch.Renamed modules makes it harder to do it that way as we could loose the commits under former module name if we aren't careful enough.
But I see no comment about the issue of renamed modules.For the added burden on the module migration and the reviews.And because we already have the readme that clearly states what is ported and what is not.Plus, contributors are used to the previous workflow.Moreover, to avoid corner case like loosing a part of the history.And last but not least, because I don't want to mess the history with commits like translation or massive update which where applied on multiple addons:+1 to keep the current process, remove unported modules since 2 versions + set everything as uninstallable.
(btw what to do with modules which were ported but not merged yet ?)Jairo and Dave, seems like a great idea!I have proposed a code sprint topic "Monitoring your Odoo stack using Prometheus" in https://docs.google.com/docume
nt/d/19Wgdmnu5SPSHSLUM7gnBLHWd n9gJvAauVhsSBqkpqE4/editEl mié, 27-09-2017 a las 16:03 +0000, Jordi Ballester Alomar escribió:Anyone interested to work on defining a Dockerized Munin to monitor Odoo? We are working on this topic.I'd be interested if it were Prometheus instead. Basically every modern piece of software in our stack provides Prometheus endpoints, since it seems to have revolutioned the monitoring landscape.You have plug & play monitoring available for Docker and Gitlab for instance, which are essentials for us.What do you think?--