PMC Architecture Meeting 20100324

From ADempiere
Revision as of 23:47, 5 April 2010 by Viola (Talk) (→‎Summary)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Date: 2010-03-24
Time: 7AM GMT
Venue: irc #adempiere-team
Support Spreadsheet: Adempiere PMC Architecture
Chat times in GMT-5

Agenda

  • Mercurial move?
  • Opinions about unplugging unmaintained or underdeveloped extensions from core (CM, HTML UI, Posterita)
  • OSGi discussion
    • OSGi metadata vs AD? (Only short review)
    • About branch handling: Introducing plugins is about code reorganisation, which is hard to do in a branch - how to deal with that?
  • Continue Review Wishlist
    • only priority high, per topic, starting at #11:
      • author shortly explains topic
      • others agree on priority
      • discussion on first tasks for the topic, put them on the task list
  • Opinions about function based indexes in seed database [1] [2]
  • One month of PMC meeting: Are we on the right way? Fast enough?
  • Other items?

Summary

  • Move to Mercurial
  • Unplugging unmaintained modules
    • CM (Content management), HTML UI, Posterita, Knowledge Base, Training, ServiceLevel, etc
    • Delete or Inactivate?
    • Process:
      • discuss it in forums - explain that functionality is candidate to be inactivated
      • inactivate all dictionary entries - move classes out of adempiere - create a 2pack to recreate/reactivate those dictionary entries
      • next release is candidate simply to be deleted from dictionary
    • 2pack needs to be stable for this
  • Function based indexes
    • Performance vs. Compatibility
    • FBI are not available on all target platforms (eg mysql)
    • So they cannot be used for validations
    • But they can (should) be enabled) in the seed of dbs upporting them for better performance

Chat

(01:59:13) viola [~viola@p57A1B34E.dip.t-dialin.net] entered the channel.
(01:59:24) viola: hi all
(01:59:48) CarlosRuiz: Hi Jörg, hi all
(02:01:54) viola: starting architecture?
(02:02:04) CarlosRuiz: yep
(02:02:19) viola: Agenda is here: http://www.adempiere.com/index.php/PMC_Architecture_Meeting_20100324
(02:02:27) viola: any changes?
(02:03:11) viola: I have one: One month is over with these PMC meeting
(02:03:15) viola: Time for a review?
(02:03:34) CarlosRuiz: ok
(02:03:47) viola: Adding it...
(02:04:21) viola: done
(02:04:30) viola: OK Starting with #1?
(02:04:40) viola: Mercurial move
(02:05:19) viola: I think we have (at least tony;-) have a plan - time to ask community?
(02:06:05) CarlosRuiz: let me check the spreadsheet ....
(02:06:58) CarlosRuiz: he already reorganized it
(02:08:05) CarlosRuiz: for me it's ok - just the doubt about name of trunk / is it ok to rename it to development? what do you think?
(02:08:24) viola: I would do so - eliminating misunderstandings
(02:09:56) viola: though these branches...
(02:10:01) viola: I have to ask tony again
(02:10:20) viola: aren't branches represented in hg through different heads?
(02:10:32) viola: should there really be distinct folders for them
(02:10:50) viola: (in the main rep I mean)
(02:11:42) viola: anyway - are we not required to ask community about the move?
(02:11:49) CarlosRuiz: yes
(02:12:01) CarlosRuiz: and I agree, time to move the discussion there
(02:12:10) hengsin: agree
(02:12:21) viola: ok - do you open a forum thread, carlos
(02:12:42) CarlosRuiz: sure, I'll do
(02:13:07) viola: OK then... #2: Opinions about unplugging unmaintained or underdeveloped extensions from core (CM, HTML UI, Posterita)
(02:14:11) viola: I have no doubt - if not maintained - mark it as such
(02:14:41) viola: by: Moving code to contrib repository
(02:15:01) viola: and throwing it out of core
(02:15:31) viola: question is: how to identify these modules properly?
(02:17:48) CarlosRuiz: from the architectural POV - the correct approach could be to delete the dictionary entries and create a 2pack for them in case somebody wants to recreate it ?
(02:17:48) hengsin: the code is mostly within their own folder
(02:18:36) hengsin: carlos, sql script should be more appropriate here since 2pack isn't really solid yet.
(02:18:41) viola: carlos: yepp (then we can easily convert them to plugins;-)
(02:18:46) CarlosRuiz: specially thinking about CM - it has lots of dictionary entries
(02:18:46) CarlosRuiz: posterita and HTML are mostly code
(02:19:00) viola: --- ahm waht is CM?
(02:19:20) hengsin: I think we just need to deactivate instead of drop the dictionary entries for now
(02:19:22) CarlosRuiz: content management - an underdeveloped module inherited from compiere
(02:19:58) viola: thx - are you talking about db seed or migrating existing dbs
(02:20:08) CarlosRuiz: both
(02:21:33) viola: about how much work are we talking - anybody to volunteer?
(02:22:22) hengsin: I will do for the html ui
(02:22:57) CarlosRuiz: I can try to help with posterita - but I'm not sure if it can be done for the next release
(02:23:24) CarlosRuiz: and about CM we need to define how to do it properly - if inactivate or delete+2pack
(02:23:46) CarlosRuiz: but it's not an urgent topic - we can discuss it after next release maybe
(02:23:53) viola: ok
(02:24:11) viola: wait a moment
(02:24:22) CarlosRuiz: maybe we can do it better with 3pack
(02:24:29) hengsin: carlos, what's the issue ?
(02:24:39) viola: this group is not meant to do such work alone
(02:24:39) viola: I appreciated you two are volunteering
(02:24:51) viola: but we should have a process to ask community for help
(02:25:49) hengsin: I've already done a bit for html ui at my local workspace so it is ok for me to finish it.
(02:25:58) viola: ok
(02:26:21) CarlosRuiz: agree with Jörg, we can ask for community help about posterita
(02:26:24) hengsin: carlos, inactive is easy and as we have discuss in previous meeting - inactive then delete after one more release
(02:27:24) viola: yeah that seems ok
(02:27:34) CarlosRuiz: hengsin, I'm not friend of delete - but I just added this new component (2pack package to allow easy recreation of the deleted entries) - so I'm prone for delete if accompanied by a 2pack
(02:27:59) CarlosRuiz: I'm ok with inactivate as first step, and second step delete+2pack
(02:28:22) CarlosRuiz: but I don't feel totally ok with delete without a way to recreate
(02:28:54) CarlosRuiz: and - then it comes to my mind - if we have a way to recreate - why not delete as first step?
(02:29:13) hengsin: inactive then delete is probably easier for community to accept and it give people chance to easyly reactivate the module
(02:29:29) viola: So we have this result: hengsin move html ui out, community is asked for posterita, cm is postponed after next release?
(02:29:39) hengsin: and a 2 release notification period is propbaly enough to verify that no one really want it
(02:30:03) viola: any other module obsolete?
(02:30:33) CarlosRuiz: I think knowledge base also
(02:30:56) viola: really?
(02:31:26) viola: hmm - should we have a community process for obsoleting modules?
(02:31:32) CarlosRuiz: I don't know anybody using it - I've never read one question in forums about KB
(02:31:48) viola: ah thats an indicator
(02:32:00) viola: or it simply works...;-)
(02:32:52) viola: ok then adding KB just as CM
(02:33:22) CarlosRuiz: the other never seen is this window:
(02:33:22) CarlosRuiz: http://www.adempiere.com/index.php/ManPageW_Training
(02:33:34) CarlosRuiz: underdeveloped and never seen a question about
(02:33:57) CarlosRuiz: and this one also
(02:33:57) CarlosRuiz: http://www.adempiere.com/index.php/ManPageW_ServiceLevel
(02:34:21) viola: problem is
(02:34:36) viola: these window might be useful to someone
(02:35:09) CarlosRuiz: exactly - that's why I prefer not to delete without a way to recreate it in case somebody is using it
(02:35:18) hengsin: yes, it could be for any that we declare as unmaintain - that's why I prefer an inactive cycle of 2 release before we remove it
(02:36:06) viola: ok i got you - but then we'd need a list of deleted modules together with their PackOuts
(02:36:22) viola: so that before starting a development one can browse there
(02:36:45) viola: hmmm - maybe that should really be plugins eventually
(02:37:15) CarlosRuiz: so, this could be the process:
(02:37:15) CarlosRuiz: 1 - discuss it in forums - explain that functionality is candidate to be inactivated
(02:37:15) CarlosRuiz: 2 - inactivate all dictionary entries - move classes out of adempiere - create a 2pack to recreate/reactivate those dictionary entries
(02:37:15) CarlosRuiz: 3 - next release is candidate simply to be deleted from dictionary
(02:37:52) viola: step 2 in release N, step 3 in Release N+1?
(02:37:56) hengsin: 2pack shouldn't be an option until it is declare stable
(02:38:35) viola: we should talk about dictmigration (aka 2pack or sql migration)
(02:38:58) CarlosRuiz: the issue with migration scripts is they are not idempotent
(02:38:58) CarlosRuiz: 2pack is
(02:39:40) viola: yes - the developper must take care of this - and 2pack finalization increases in priority
(02:39:48) CarlosRuiz: IMHO 2pack is stable - but incomplete, and hard to keep in sync with latest dictionary entries
(02:39:48) CarlosRuiz: I think we can discuss (here or in next meeting) if 3pack (improvements from hengsin) is an option for soon integration
(02:39:56) viola: carlos agree to you process
(02:40:38) viola: ready to move on in agenda?
(02:40:46) hengsin: lets move on
(02:40:53) CarlosRuiz: yep
(02:41:01) viola: lets do OSGi only short this time
(02:41:17) trifon: morning
(02:41:34) trifon: i'm a bit late and short of time but hope that can attend
(02:41:49) viola: metadata last time ended with: we want AD data and we want it easy for the developer
(02:42:03) CarlosRuiz: [ thanks trifon ]
(02:42:16) viola: I'll come up with a proposal - but this will involve 2pack - so same prob here
(02:42:20) viola: hi trifon!
(02:43:00) viola: can we shortly talk about the second point
(02:43:15) viola: we are in principle ready
(02:43:24) viola: to move code out of the core into plugins
(02:43:33) viola: (starting with accounting)
(02:43:46) viola: but that would involve realyy moving the classes
(02:44:04) viola: and here the trivial problem arises: this is hard in a branch
(02:44:18) viola: merging becomes a nightmare
(02:45:28) viola: any suggestions?
(02:46:01) trifon: viola: can we organize them as separate projects in eclipse?
(02:46:05) trifon: will it help?
(02:46:21) viola: sure they will become projects
(02:46:37) viola: but if you want to merge that back to trunk
(02:46:50) viola: you get problems because their location changed
(02:46:54) trifon: can we organize trunk by this way?
(02:47:12) viola: hmmm - good idea
(02:47:24) CarlosRuiz: viola: that include moving the X_ and I_ classes per module?
(02:47:25) CarlosRuiz: asking this because it will imply a subdivision of entitytype "D"
(02:47:42) viola: but this would already be the start of modularization on trunk
(02:48:00) viola: carlos: not sure - but i think yes
(02:48:12) trifon: Carlos "D" can be in different modules?
(02:48:18) trifon: what is the issue which you see?
(02:48:27) CarlosRuiz: yes - but GenerateModel will become a nightmare
(02:48:55) trifon: why?
(02:49:12) viola: because it must geenrate different classes in different places
(02:49:41) trifon: maybe we should take into account module and put classes into different folderrs.
(02:49:43) viola: so here is another topic to think about before really starting to factor out
(02:50:03) trifon: issue is dependency i think.
(02:50:23) viola: I'll first tackle that and come back to the merging question later....
(02:50:31) trifon: ok.
(02:50:50) viola: anyone agrees to skip OSGi with that?
(02:51:13) CarlosRuiz: do you mean move on the next item?
(02:51:21) viola: yes ;-)
(02:51:25) CarlosRuiz: ok - agree
(02:51:49) viola: and I propose to move to the FBI topic for the last minutes
(02:51:57) hengsin: Jorg, the merge issue would be resolve if we are on DVCS
(02:52:08) hengsin: svn suck on that ...
(02:52:31) viola: hmm I don't clearly see that for now but I'm eager to try it!
(02:52:45) viola: Opinions about function based indexes in seed database https://sourceforge.net/projects/adempiere/forums/forum/610548/topic/3383439 https://sourceforge.net/tracker/?func=detail&atid=879332&aid=2843507&group_id=176962
(02:53:09) hengsin: I'm on the pro side
(02:54:08) viola: carlos is right: db independence must be taken care of
(02:54:10) trifon: just a note: having things on branches means that very few devs work on it. This slows down the process. idea is to move faster in modularization.
(02:54:37) hengsin: a db that can't support fbi most probably wouldn't run adempiere well, it will be turtle speed
(02:54:50) trifon: about FBI. i'm pro to see them in trunk as they help to protect integrity.
(02:55:03) CarlosRuiz: AFAIU mysql doesn't support FBI - and it's the fastest DB
(02:55:27) trifon: fastest DB only when not using transactions.
(02:55:59) viola: ok but mysql definitely is a target db, right?
(02:56:36) trifon: i think that many people will move to postgres now.
(02:56:49) CarlosRuiz: for me a "target" DB is any supported by hibernate (or something similar) in future
(02:56:49) CarlosRuiz: I mean - I would prefer we think on "hibernate" support instead of any specific db
(02:57:03) viola: but: we have different seeds for different dbs, whats the point of leaving the FBIs out of the mysql seed
(02:57:38) trifon: vioola: good point. so we can have postgres with FBI and mysql without.
(02:57:46) hengsin: carlos, thats BS
(02:57:59) viola: BS?
(02:58:08) hengsin: mysql is the fastest db is BS
(02:58:20) CarlosRuiz: trifon: that's why I proposed postgres FBI as extension - because it's specific for one DB
(02:59:05) viola: carlos what exactly means extension here? - the postgres seed would include them?
(02:59:59) CarlosRuiz: I mean - something not supported on ALL databases must not be in core
(03:00:00) trifon: my idea is by default seed to be MAX protectes. integrity of data, because people try stupid things.
(03:00:01) viola: hengsin: BS does not stand for what I am thinkg it stand for or? ;-)
(03:00:34) CarlosRuiz: trifon: that's the benefit - but we lose the ability to run in mysql
(03:00:35) hengsin: Jorg, haha, it is :)
(03:00:43) viola: ups
(03:01:07) trifon: CarlosRuiz: droping something is easier than adding.
(03:01:18) trifon: so to run on mysql we will need to drop this indexes.
(03:01:27) viola: carlos can you comment on the "different seed" comment?
(03:01:49) trifon: it sounds more easy. also please take into account that adempeire run on oracle and postrges now. MySQL is just POC.
(03:01:51) CarlosRuiz: and - the mysql port will be very poor compared to postgres port - because we didn't write the validations in java but in db indexes
(03:02:24) viola: Oh no! - Validations in java must not be dropped in favor of FBI!
(03:02:27) CarlosRuiz: question is: do we want in future to support more databases? do we want to support a database not supporting FBI (like mysql or hsql) ?
(03:02:44) hengsin: carlos, validation is fine but out of the box performance suffer greatly without fbi
(03:02:58) viola: sorry my time runs out - carlos: we want more dbs!
(03:03:12) trifon: we must not drop validation from java code, but we must protect DB.
(03:03:24) hengsin: some report and search run 10 time slower without proper fbi in place
(03:03:27) viola: sorry guys - have to leave
(03:03:34) viola has left the channel.
(03:03:38) trifon: me tto. i have to leave to.
(03:03:42) trifon has left the channel (quit: Quit: Leaving).
(03:04:28) CarlosRuiz: hengsin: my worry is because if you see the original tracker - somebody proposed to add a validation in a function based index - instead of writing it in java
(03:05:44) hengsin: yeap, I agree we can drop the use of that for validation but for performence, there is no other way around it.
(03:07:11) CarlosRuiz: about performance - I'm not sure it's needed in seed db - I would prefer to have performance as an add-on package
(03:07:11) CarlosRuiz: for example it's not easy to tune financial reports - because every report can need different index
(03:08:26) hengsin: yes and there's always a but :) there some general good indexes that can be included and people will look at your slow out of the box performance as bug too.
(03:09:31) CarlosRuiz: in such case - if the index is not used for validation, but for performance, I can be ok that mysql port doesn't have them, but postgres do
(03:09:31) CarlosRuiz: what I cannot support is having validations in one port and not in another
(03:10:47) hengsin: alright, agree to that.
(03:12:15) CarlosRuiz: so  :-) meeting is over - interopen is here?
(03:12:35) interopen: yes, here, hello Carlos

Retrieved from "http://www.adempiere.com/index.php5?title=PMC_Architecture_Meeting_20100324&oldid=22914"