IRC logs of #tryton for Monday, 2017-08-07 #tryton log beginning Mon Aug 7 00:00:01 CEST 2017
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton02:09
-!- csotelo(~csotelo@2001:1388:49c6:f9a5:a328:3589:be40:bafd) has joined #tryton02:19
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton02:33
-!- kobain(~kobain@unaffiliated/kobain) has joined #tryton04:31
-!- semarie(~semarie@unaffiliated/semarie) has joined #tryton05:48
-!- semarie(~semarie@unaffiliated/semarie) has joined #tryton06:56
-!- Timitos( has joined #tryton07:23
-!- zmijunkie( has joined #tryton08:59
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:09
-!- csotelo(~csotelo@2001:1388:49c6:f9a5:a328:3589:be40:bafd) has joined #tryton09:21
-!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton09:53
-!- orphean(~Orphean@ has joined #tryton09:55
-!- udono( has joined #tryton10:08
-!- thaneor1( has joined #tryton10:12
-!- nicoe( has joined #tryton10:28
sisalporphean: about working hours, it doesn't look as refactoring but more a functional change.11:10
sisalpIf you have a requirement to consider work-time by resource (why only employees ?) it may fit in three level : a module added to the standard, an industry/local/business specific or a custom reusable code. In some cases a mix of the three levels.11:13
sisalporphean: the idea is that the standard should not become specific.11:15
orpheani agree entirely11:16
orpheanthe more flexible the better11:16
sisalporphean: The problem we have imho, is that only the standard has an elaborated gouvernance.11:17
pokolisisalp: agreee, but people can do whatever they want outside of standard :)11:18
sisalppokoli: this is the custome reusable : If we know where the code is, we can do anything we want.11:19
sisalppokoli : on this side also, nothing is defined at global level.11:20
sisalppokoli: the only identified source of custom reusable was ZikZakmedia and NanTic, but doesn't seem operational.11:21
pokolisisalp: the website is partially operational, but they have the source code still available11:23
sisalppokoli: last time I visited, I could figure out what I could do with it.11:24
pokolisisalp: last time I talked with them about it, they said that they wanted to change some things11:25
pokolisisalp: but AFAIS it's in the same state as it was before11:26
sisalppokoli: We could have improvements in this domain. If a repository in only feeded by a single company, it is a waste of time for this company.11:28
sisalppokoli: so sharing info, links and code should be organized globally.11:29
pokolisisalp: agree, and I had some discussions about it with nantic's guys11:30
pokolisisalp: unfortunatly, we haven't reached any agreement11:30
sisalppokoli: then, if it succeeds, custom code can be refactored to address industry/business specifics which a gouvernance of common modules.11:30
cedksisalp: this is what we do at, we have process, standard etc.11:32
cedkI do not see the goal to move it outside11:32
sisalpcedk: I don't propose to move it outside if it makes sens.11:33
pokolisisalp: indeed, if some parties agreee, they can have some set of "standard" modules that fit the needs of all parties11:34
sisalpcedk: is there a place, where a developper can put some garbage code just in case someone else would like to have a look at it ?11:34
pokolicedk: probably it does not make sense to have verticalization modulesas part of tryton.org11:35
pokolisisalp: 1. Create a discuss topic (without topic), 2. Create and issue and codereview11:35
pokolis/without topic/without code/11:35
cedksisalp: we do not have the resource to manage a code hosting11:35
cedksisalp: I think verticalization can fit in the standard module but usually people do not want to invest on doing standard11:36
pokoliwe also have tryton-contrib mailing list:!forum/tryton-contrib11:36
cedkpokoli: I do not think we should encourage to have codereview that does not aim to be included11:37
pokolicedk: then probably we should encorage using tryton-contrib mailing list11:38
sisalpcedk: We should open a topic indeed. I think rthe future is to have good verticalisations, outside the standard.11:38
pokoliwith custom code repository (there are a lot of free code hosting plataforms now)11:38
cedkI remember someone from semilimes created a website for that11:39
cedkalso nicoe was working on a website based on PyPI11:39
pokoliACTION also remembers the website and remembers was listing probably 1200 repositories11:39
cedksisalp: also
cedkI personnaly do not think we should value repository but only released package11:40
cedkhaving release shows maturity11:40
pokoliagree, it's a pitty that there is not so much people releasing to PyPI11:42
sisalplet's take an example : associations : they are many kinds, and I don't think association specific should be included in standard.11:43
sisalpit doesn't mean the association vertical doesn't require some collaboration, care and maintenance.11:44
sisalptoday we can only say : no this is not in standard.11:45
pokolisisalp: so one an association vertical it's developed, it can be proposed to be added to the standard if it mets the requirements11:46
pokolisisalp: and then it will be on standard :)11:47
sisalpI don't think it should11:47
cedksisalp: why could not an "assocations" module be in standard?11:47
cedkfor me, the only reason to not include something in standard is because it is not generic or for general usage11:48
cedkso often it is because it is ugly and hacky11:48
sisalpcedk: yes this is the reason11:48
sisalpcedk: association is specific in large parts compared to erp business.11:51
sisalpcedk: it is not only adapting the erp, or adding features to the erp.11:51
cedksisalp: I can not really talk about that without concrete example11:55
cedkbut for me, as Tryton member, I always want to have module standardized11:55
cedkof course, they could have external project and Tryton project can collaborate with them11:56
cedkbut it should not be our main goal11:56
cedkfrom my experience with GNU Health, it is difficult to know in advance if it will be easy to collaborate11:57
sisalpcedk: what do you call Tryton project ? and who do you include in "our main goal" ?11:58
cedksisalp: Tryton project = everything managed by the Foundation11:59
sisalpcedk: for me Tryton community perimeter  is not clearly delimited, so a grey zone at the edge could contribute more code.12:00
cedksisalp: I would call that the "Tryton ecosystem"12:01
cedkand for that, I think it should be a subset of the Python ecosystem12:01
sisalpcedk : external projects are difficult, because a vertical has some part which must be standard, and some part which is specific.12:06
sisalpok, this requires more thinking on my side. I'm sure well have to talk about this again and again ;-)12:07
cedkexternal projects are difficult because like any project, it requires times, commitment and perseverance12:14
pokolisisalp: if a good standard is available, developing the specific it's easy12:16
sisalppokoli: yes for the specific and yes for the custom. Specific will enrich Tryton "ecosystem", custom will not.12:24
pokolisisalp: I will say, it's useless to make custom code publicy available12:35
cedkpokoli: I even think, it hurts because it adds noize12:38
pokolicedk: i was thinking it too, but I wasn't brave enought to said it loud :)12:39
orpheantryton is gpl not lgpl right? how does the license affect custom modules?12:41
cedkorphean: it is written in the license :-)12:42
-!- alexbodn(~alex@ has joined #tryton12:42
cedkorphean: derivative works must be follow but the definition of derivative work is complex12:42
orpheani was under the impression that standard gpl on a web service was still a grey area12:43
orpheansomethign to do with the hazy definition of "distribution"12:43
orpheananyw historically is there a module naming convention for bespoke or modified modules?12:50
orpheanjust organisation prefix?12:51
pokoliorphean: you can use what ever prefix you want to name your modules12:53
cedkorphean: yes see our cookiecutter template12:53
pokoliorphean: just preserve trytond for standard ones, and it may be good to check if no module are using the same prefix12:55
sisalppokoli: cedk: customer funding is a mess, but do we have alternatives ? If you think no good vertical can emerge from custom code, then whci alternative do you have in mind ?  Investments in vertical lead to what was called external projects above. Is it the way to go ?12:58
pokolisisalp: nothing prevents external projects to join standard. It's only an investment decision on the project maintainers12:59
pokolisisalp: the problem is that usally its easier to live outside of standard, as it give you more flexiblity13:00
-!- mariomop(~quassel@ has joined #tryton13:09
-!- alexbodn(~alex@ has joined #tryton13:20
sisalppokoli: if industry -specifics join the standard, the standard is no longer standard, it becomes a collection of specifics.13:33
sisalppokoli: Am I wrong if I say that, on Tryton, no specific is driven by a community, only by a company ?13:36
pokolisisalp: i understand standard as a way to develop and maintain generic modules13:36
pokolisisalp: specific modules can be part of what we call "standard" here13:36
sisalppokoli: ok, for me standard is part of the official 6 months release planning.13:37
pokolisisalp: lets use instead of standard :)13:38
pokolisisalp: regarding last question, what do you understand by specific? is gnuhealth and specific?13:38
sisalppokoli: Examples of industry-specifics that come are gnu-Health, Occhiolino, Coog, Nereid. I may miss some.13:41
pokolisisalp: correctme if i'm wrong, but there is a comunity behind gnu-health13:42
pokolibtw, is nereid still in development?13:42
sisalppokoli: gnu-health may be driven by gnu-solidario, indeed, thymbra may be just a technical contributor.13:44
sisalppokoli: nereid is stopped as an open tryton project. May be the authors expected a community to form around nereid and it didn't happen despite market interest.13:46
pokolisisalp: indeed i contributed to nereid some time ago, but latests version is 3.4, which is not usable for us13:48
sisalppokoli: of course, classification standard-release/industry-specific/custom is to be discussed case by case.13:48
pokolisisalp: i think so. but specific can be merged to if the authors are willing to make the effort13:50
pokolisisalp: and probably most modules must be first written as third party modules, and then adopted by tryton.org13:51
sisalppokoli: my turn to disagree ;-)13:51
pokolisisalp: btw, did you know incubator projects on larger open source projects? (i.e: Apache, Openstack, Kuberentes)13:51
sisalppokoli: a good standard module should be discussed as such in its early times to be seamlessly integrated. If it is not designed collectively at first, it has little chance later.13:53
sisalppokoli: Thinking about mail discussion recently.13:55
pokolisisalp: what I mean is that: you can deploy a module in discussion (or even before discussion) as third party module, while you discuss it's dessing collectively13:56
sisalppokoli: yes, the "third party module referes to the author more than its genericity. standard should be standard-driven and it is well done today.13:57
sisalppokoli: while industry-specifics should be driven by specialists and use-cases, closer to customers' funding.13:59
pokolisisalp: I think we should try to "sell" the standard benefits to the third party module authors14:00
pokoliprobably it's work a talk on the next Unconference14:00
sisalppokoli: its a life long discussion. We already had exchanges on previous unconferences and of course we will discuss it again ;-)14:02
-!- mrichez( has joined #tryton14:03
pokolisisalp: the beers and this discussions are the main reasons of that unconferences exists :)14:03
sisalppokoli: thank you for this discussion :-)14:03
pokolisisalp: same to you :)14:04
-!- csotelo(~csotelo@ has joined #tryton15:34
orpheanAs a trivially small concrete example: I would like to link a material (product) to a manufacturer (party/company) and available regional resellers (parties/companies).16:01
orpheanAs far as I can see there is no existing official module that links a product to a party other than product carrier, but manufacturer/supplier is not a carrier.16:02
orpheanSo I would have a few options for implementing16:02
cedkorphean: there is supplier information on the product16:03
orphean1. Create an issue and submit a code review to the official product module16:03
orphean2. Create an issue and define a new module to inject the feature into product16:03
orpheanIssue with one would be that not everyone might want this field on product so it's cluttering their form16:04
orpheanIssue with two is you start to clutter the official modules with tiny functionality additions16:04
orpheanI don't see any field for manufacturer or suppliers on product?16:05
orpheanunless the expected way is to install attributes and the manufacturer as an attribute16:07
pokoliorphean: do you have the purchase module installed? Is the product marked as purchasable?16:08
orpheani do not have the purchase module installed16:08
pokoliorphean: so you need the purchase module in order to define the supplier information of products16:09
orpheanthe way the purchase module is set up doesn;t really work with my organisation16:09
orpheanas we are not retail/ resellers16:09
pokoliorphean: could you describe your organization setup?16:09
orpheanwe are a painting contractor16:10
orpheanwe make offers for contracts often of fixed price or cost plus16:11
orpheanwe may supply material directly but rarely16:12
orpheanit is more often included in the fixed price16:12
pokoliorphean: but you buy once the contract is accepted?16:15
orpheanwhen we need to order a product it will be a specific product from a specific manufacturer, but the supplier is often a reseller more local to the project location16:15
pokoliorphean: a contract includes only the painting services? or only the material required for the painint?16:16
orpheanit can vary16:17
pokoliorphean: do you have products in stock? or you purchase on demand?16:17
orpheanbut normallyit includes skilled labour, materials, management16:17
orpheanand any equipment, machinery, auxilaries16:18
orpheanand usual overheads relating to all of those16:18
pokoliorphean: but there is some point, that you will purchase the materials to somebody else16:20
pokoliorphean: this is managed by the purchase module16:20
orpheanthe umbrella term you could use to classify it i guess would be construction /engineering contracting16:20
cedkorphean: I do not see why you can not use purchase module16:21
-!- udono1( has joined #tryton16:23
orpheanto begin with i was looking to put together a database for coating materials, to me at least, the information about a material/product is independant conceptually from the concept of purchase16:24
orpheani'll check out the purchase module though16:25
-!- udono( has joined #tryton16:26
-!- kstenger( has joined #tryton16:27
-!- udono2( has joined #tryton16:27
cedkorphean: at some point, we have to link things together otherwise we will have 1 module per fields16:30
-!- udono( has joined #tryton16:30
cedkso you can install the module and not use some of its features16:30
orpheandigressing for a moment: is it normal to require a daemon restart after running trytond-admin --all?16:33
orpheanthe modules show up on the client but they wont activate unless the daemon is restarted16:33
cedkorphean: yes16:33
orpheanok thanks16:34
orpheanwell back to the product manufacturer query no wi have purchase module installed16:36
orphean(and i guess my point here is to ask about small feature implementation process rather than this specific feature)16:37
orpheani would still want to record the product manufacturer / brand separately from the product suppliers16:38
orpheanthe question then is if i like the official module generally but there is a small specific change i want to make to it for my own organisation, wuld you guys be happy to see it on the bug tracker at all? and if so as an update to the existing module or a new module?16:39
orpheansay, adding 1 field16:40
orpheantell me if im being pedantic here :)16:40
kstengerorphean: probably would be better to discuss each need on the mailing list. Those kind of changes are added to tryton only if they are generic enough16:47
-!- udono( has joined #tryton16:48
kstengerI have a custimer willing that almost every single change he needs goes on a separate module (he wants to identofy them by name), I wonder how much efficiency would be affecting him on the long term17:09
kstengerdo you think this would be an issue?17:10
cedkorphean: feel free to submit proposal but as maintainer I often initially say 'no' so you will have to argument it well17:22
cedkkstenger: a very large number of module could be a performance penalty17:23
cedkkstenger: on startup, it will be expensive17:23
cedkkstenger: but also for any request as mro will be very hudge. This means many Python method call which is known to be slow17:24
-!- orphean(~Orphean@ has left #tryton17:26
-!- orphean(~Orphean@ has joined #tryton17:26
-!- smarro(~sebastian@ has joined #tryton17:36
kstengercedk: yes, you confirmed my thought, thanks17:42
-!- Telesight( has joined #tryton18:13
-!- JosDzG(~Thunderbi@ has joined #tryton18:17
-!- zmijunkie( has joined #tryton18:49
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton20:50
-!- nicoe(~nicoe@ has joined #tryton21:50
-!- semarie(~semarie@unaffiliated/semarie) has joined #tryton22:01
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton22:13
-!- thaneor( has joined #tryton22:15

Generated by 2.11.0 by Marius Gedminas - find it at!