| chat.freenode.net #tryton log beginning Wed 10 Jul 2019 12:00:01 AM CEST | ||
| -!- yangoon(~mathiasb@210-163-142-46.pool.kielnet.net) has joined #tryton | 22:01 | |
| -!- yangoon1(~mathiasb@92.117.244.93) has joined #tryton | 22:59 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | 23:08 | |
| -!- yangoon(~mathiasb@mue-88-130-74-046.dsl.tropolys.de) has joined #tryton | 23:54 | |
| -!- yangoon1(~mathiasb@i59F4BCEC.versanet.de) has joined #tryton | 02:53 | |
| -!- springwurm(~Springwur@5.104.149.54) has joined #tryton | 04:50 | |
| -!- rpit(~rpit@p200300C88F413D0069F553E02A39C574.dip0.t-ipconnect.de) has joined #tryton | 06:06 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | 06:51 | |
| -!- udono(~udono@186-061-210-188.ip-addr.inexio.net) has joined #tryton | 06:57 | |
| -!- mrichez(~Maxime@mail.saluc.com) has joined #tryton | 07:01 | |
| pokoli | I'm wondering if our pollicy allows to backport https://bugs.tryton.org/issue8469 | 08:04 |
|---|---|---|
| pokoli | IIUC this fix requires a database update and it should not be backported | 08:04 |
| pokoli | on the other hand I think it will be good to backport so the issue is fixed on new 5.2 database versions | 08:05 |
| cedk | pokoli: not for me | 08:17 |
| cedk | that's the problem when people test after the release instead of before | 08:18 |
| pokoli | cedk: see your point but what it concers me is that we have something that will never work correctly on version 5.2 | 08:24 |
| pokoli | and one of my ideas about when created https://bugs.tryton.org/issue7736 is to ease testing of trunk version before the release | 08:26 |
| cedk | pokoli: there are many things that never works correctly | 08:30 |
| pokoli | yeah, but this is one that we can easly fix | 08:33 |
| pokoli | at the end is not a big problem as I imagine most of the integrators will fix this things on their deployments of tryton | 08:34 |
| pokoli | but for people using Tryton as is give the feeling that there is something that it's fixed but only partially | 08:35 |
| cedk | pokoli: yeps but it is the fault of the community who is not testing on time | 08:36 |
| cedk | nor reviewing enough | 08:36 |
| pokoli | of course better testing will allow us to catch this kind of bugs after the relase, but I'm not sure if we will be able to catch always all bugs before the release | 08:36 |
| -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton | 08:59 | |
| -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton | 09:53 | |
| semarie | usually, does running with tip is doable in production environment, or it should be avoided ? | 10:01 |
| pokoli | semarie: usually is doable | 10:02 |
| pokoli | semarie: problems may arraise when you have custom modules and a new change is introduced on trunk that require your modules to be adapted | 10:02 |
| pokoli | semarie: otherwise trunk is quite stable | 10:02 |
| semarie | yes I understand the problem with customs modules | 10:02 |
| pokoli | semarie: if you use only standard modules it's a matther of keeping the clients up to date when updating the server | 10:05 |
| semarie | ah yes, the desktop client would be more complex to maintain | 10:06 |
| pokoli | semarie: personally I've started some production deployments on trunk with the idea to migrate to new version once it's released | 10:06 |
| pokoli | semarie: another thing that you should take care is that trunk changes are not translated until the release | 10:06 |
| semarie | ok. translation would be too much for my users... | 10:07 |
| pokoli | semarie: but you will only miss the translation of new strings | 10:25 |
| pokoli | semarie: there was an script to donwload new translations from pootle, not sure if it also works with weblate | 10:26 |
| -!- mariomop(~quassel@host79.201-253-68.telecom.net.ar) has joined #tryton | 10:52 | |
| -!- Timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton | 11:54 | |
| -!- springwurm(~Springwur@5.104.149.54) has joined #tryton | 12:03 | |
| semarie | cedk: I updated the review for issue8478, but not checking if field is a Function before looking at field.setter seems wrong to me | 13:51 |
| semarie | (even if try/except will do it) | 13:51 |
| pokoli | semarie: why? what you propose instead? | 14:06 |
| semarie | pokoli: I am unsure it is readable enough. the isinstance(field, Function) make the intent more evident | 14:09 |
| cedk | semarie: my comment #5 was only for "setter != None" not to remove the isinstance test | 14:09 |
| semarie | cedk: so discarding the field if it is a Function ? even if the Function has a setter ? | 14:11 |
| pokoli | semarie: for me only makes sense to discar functional fields without setter functions | 14:27 |
| semarie | pokoli: thanks. I updated the review | 14:32 |
| cedk | semarie: no, I mean testing "!= None" should not be written like that but just "setter" | 14:32 |
| semarie | ah ok. I (finally) understood | 14:33 |
| semarie | so I think it still apply with my current review: return field.setter is not None | 14:34 |
| semarie | I will change it to: return field.setter | 14:34 |
| cedk | semarie: yes it is Python way | 14:35 |
| -!- udono1(~udono@186-061-210-188.ip-addr.inexio.net) has joined #tryton | 17:38 | |
| -!- udono2(~udono@186-061-210-188.ip-addr.inexio.net) has joined #tryton | 17:40 | |
| -!- udono(~udono@186-061-210-188.ip-addr.inexio.net) has joined #tryton | 17:43 | |
| -!- udono(~udono@186-061-210-188.ip-addr.inexio.net) has joined #tryton | 19:01 | |
| -!- semarie_(~semarie@unaffiliated/semarie) has joined #tryton | 20:00 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!