Modularization/IRCLOGS/20090422.log

(14:54:21) _ch_ [n=Cynthia@218.249.75.106] 杩涘叆浜嗚亰澶╁銆?/font> (15:01:14) kr_ [n=Kay@nat/sun/x-50cb55297df67c70] 杩涘叆浜嗚亰澶╁銆?/font> (15:01:36) kr_ 绂诲紑浜嗚亰澶╁(quit: Client Quit)銆?/font> (15:02:12) kr_ [n=Kay@nat/sun/x-c9afb9b4e1c2235f] 杩涘叆浜嗚亰澶╁銆?/font> (15:02:22) xiuzhi [n=xiuzhich@218.249.75.106] 杩涘叆浜嗚亰澶╁銆?/font> (15:02:28) liutao: Kay:Good morning
(15:02:31) xiuzhi: hi akll
(15:02:39) xiuzhi: kr_: moin
(15:02:53) kr_: good morning :-)
(15:03:09) _ch_: Good morning.
(15:04:10) liutao: Kay:should we wait for Ingo ?
(15:04:44) xiuzhi: kr_: How do you think orcale buyout?
(15:04:56) kr_: Wednesdays unfortunately are not possible for Ingo, he would prefer Monday or Tuesday ...
(15:05:30) kr_: xiuzhi: I may not comment on this :*)
(15:06:07) liutao: Oh,Do you think if we should change the IRC meeting time?so that Ingo could join us ?
(15:06:30) liutao: The Agenda of today's IRC meeting
(15:06:30) liutao: 1.the proposal of modularization project.
(15:06:30) liutao: 2.The nscp files and the following work.
(15:06:30) liutao: 3.About the tools(what it will be look like?)
(15:06:30) liutao: 4.Open discuss
(15:06:37) kr_: if suitable for you, we may want to move the to Tuesday ..
(15:06:53) xiuzhi: kr_: I see. Most Chinese IT people talked about this these days.
(15:07:05) liutao: kr_:OK for us
(15:07:56) xiuzhi: xiuzhi: Tuesday is OK
(15:08:29) kr_: I saw the proposal sent by Liutao to Louis ...
(15:09:34) liutao: kr_: Yes,just modified a little.:)
(15:10:12) kr_: Looks fine!
(15:10:44) liutao: kr_:what should I do in the next step after the proposal?
(15:11:56) kr_: we should send the proposal to the project leads list and to dev list to gather some interest
(15:12:53) liutao: kr_:but we do not get any feedback form Louis.you mean that we should send the proposal now?
(15:16:43) kr_: some days later we than ask Louis to create an incubator
(15:16:43) kr_: liutao: Do you want to send the proposal to dev and to the project leads list? Or should I?
(15:17:44) liutao: kr_:I perfer you:)
(15:17:51) xiuzhi: +1
(15:18:07) liutao: prefer
(15:18:20) kr_: we may want to wait another day ... if Louis hadn't answered by than, I ping him again :)
(15:18:34) liutao: OK
(15:19:19) kr_: OK, I will send the proposal :)
(15:19:38) liutao: OK,Next
(15:19:38) liutao: 2.The nscp files and the following work.
(15:20:51) kr_: I think understanding the requirements for the "nscp" is easier to be discussed, than by reading the code ...
(15:21:25) liutao: We still don't know what should we do and how to do . I just installed a netbeans,and compiled OOO310_m10(have errors-solved but not best)
(15:22:18) liutao: what the nscp files is?We don't know how to use it.
(15:22:27) kr_: let me try to explain what I think the new scp should work like ...
(15:23:28) kr_: on http://wiki.services.openoffice.org/wiki/Efforts/Package_Restructuring/Modelling you find a picture of what I call "product pipeline", please have a look at it
(15:24:01) liutao: yes
(15:24:45) kr_: the picture tries to show the way from the source files to the final files ...
(15:25:11) kr_: I call these final files "deliverables"
(15:25:50) kr_: some examples for "deliverables": .msi, .tgz, .rpm, .deb, .iso ...
(15:25:50) liutao: yes
(15:25:57) liutao: I see
(15:26:23) kr_: these deliverables are what a "program manager" wants to "deliver" to his customers ...
(15:26:31) liutao: yes\
(15:27:27) kr_: so, ideally a "program manager" would just type the following into the command line (or a browser):
(15:28:02) kr_: > make openoffice.org_en_de_win32.iso
(15:28:48) kr_: this would create an iso image (suitable for burning on a CD), consisting of an Windows installation set, with the languages English and German ...
(15:29:05) liutao: yes
(15:30:27) kr_: unfortunately there are more properties than just language and OS ... e.g. version, features, brand - I listed them on the wiki page close to the picture ...
(15:30:42) liutao: YES
(15:31:17) kr_: so, what we need is something to express these properties, I tried to do this with the .nscp files ...
(15:32:02) kr_: please look into the "staroffice_retails.nscp" ...
(15:33:12) liutao: yes
(15:33:35) kr_: lines with a beginning "#" are just comments ...
(15:34:25) kr_: in this file you see, that I defined a "deliverable" called staroffice_retail ("staroffice_reatils : Deliverable")
(15:34:37) liutao: yes
(15:35:04) kr_: the syntax is simple, <identifier> : <type> { <description> }
(15:36:23) kr_: the "staroffice_retail" deliverable consists (amongst its name and the packager) of one product, called "StarOffice_9_0_1_Win32" ...
(15:36:33) liutao: So the Name is: "StarOffice Retail" and the Packer: ProductPacker [ { Packer "ooo.tgz.Packager" } ];
(15:37:00) kr_: yes, this deliverable would be a .tgz ...
(15:37:32) liutao: I see.but what the comments mean?original?
(15:38:05) kr_: I just commented some lines while playing with parser etc. ...
(15:38:26) kr_: please ignore the commented lines ...
(15:38:31) liutao: OK
(15:39:16) kr_: please have now a look at StarOffice_9_0_1.Win32.nscp ...
(15:40:30) liutao: yes,what is the load File mean?
(15:41:31) kr_: "loadFile" means, that the parser should load (include) the file whichs name has been given
(15:42:13) kr_: the identifiers of this file are than available in the loading file
(15:43:04) kr_: we may want to optimize this, so that a file may be directly loaded in-place ...
(15:43:22) liutao: OK
(15:44:16) kr_: in the "StarOffice_9_0_1 ..." file a define a product ...
(15:45:48) liutao: I know all the means in this file except Base base_domain
(15:46:40) kr_: you find the definition of "base_domain" in the file base.domain ...
(15:48:00) kr_: this file just describes the "dimensions" of the name mangling ...
(15:48:08) kr_: brnd == Brand
(15:48:24) kr_: vers == Version (E.g. OOO310m9)
(15:48:36) liutao: yes
(15:48:39) kr_: os = Operating System (e.g. Linux, Windows)
(15:48:51) liutao: I see the others
(15:48:56) kr_: arch = Architecture (e.g. x86, x64 ... or ARM :-)
(15:49:10) liutao: ARM:)
(15:49:37) kr_: these "dimensions" are needed for mangling names e.g. of .msi or .rpm ...
(15:50:16) kr_: e.g. SO_OOO310m9_Win32_x64_en
(15:50:55) kr_: means: StarOffice of the version OOO310m9 for Windows, 64bit, in English
(15:51:05) liutao: yes
(15:51:32) kr_: this is not so much important for .msi , but for other package formats ...
(15:52:16) kr_: rpm for example supports the notion of a "concrete" dependency, and that of a virtual dependency ...
(15:52:56) kr_: as an example we may have a dependency chain of "writer" -> "framework" -> "uno" ...
(15:53:39) kr_: we would express this as a "concrete" dependency ...
(15:54:27) kr_: while factoring out e.g. the languages, we get new writer packages: writer_core, writer_en, writer_de ...
(15:55:42) kr_: certainly we don't want to make the writer_core package dependent on a concrete language, but just on at least one language: writer_core -> writer_lcl ...
(15:55:56) kr_: does that make sense for you ?
(15:56:30) kr_: this dependency would be a "virtual" dependency ...
(15:57:05) liutao: YES
(15:57:20) liutao: Clearly:)
(15:57:41) _ch_: kr: what's the meaning of "Indices [ 1, 2, 3 ]" in d__os_arch_.domain.nscp, and "Indices [ 0,1 ]" d_brnd___.domain.nscp, Are the indice arrange refer something?
(15:59:53) _ch_: I have missed "to" after "refer"
(16:00:37) kr_: _ch_: yes, they do ... not all packages provide something for all "dimensions", e.g. the writer_core package does not provide anything for local or brand ... but likely for OS, ARCH and VERSION ... and these are the indices you are seeing while looking into "d__os_arch_.domain.nscp"
(16:01:13) kr_: 1 == VERSION
(16:01:20) kr_: 2 == OS
(16:01:30) kr_: 3 == ARCH
(16:02:53) _ch_: so , 0= brnd?
(16:03:17) kr_: yes!
(16:05:35) kr_: scp currently creates some kind of script, which is than executed to create installation sets ...
(16:06:16) kr_: the nscp should ideally integrate into make, allowing make to decide on creation of packages etc. ...
(16:07:37) liutao: I see.how to use the parser you send to me
(16:07:38) liutao: ?
(16:07:39) liutao: I just opened the parser using netbeans6.5 but there are errors
(16:07:46) kr_: therefor packages etc. need to mangle their properties into their names, so that we can combine any two packages into one container (AKA installation set ) ..
(16:09:45) kr_: the parser understands different commands ... please look into Main.java, their you find the "main" method
(16:10:17) _ch_: kr_:ls
(16:10:48) kr_: _ch_:??
(16:11:00) _ch_: kr_ :sorry, ;)
(16:11:17) liutao: OK I will try again.
(16:12:18) kr_: _ch_: :)
(16:15:19) kr_: to summarize: everything should work through "make", dependencies are key for creating "self contained" deliverables, "nscp" should describe deliverables ...
(16:16:24) kr_: ideally that means, that we can distribute the information of what belongs into which package into the modules ... allowing us to recombine these modules into new "products" or "deliverables" ... e.g. writer only etc.
(16:17:48) xiuzhi: kr_: OK. let's 3.About the tools(what it will be look like?)
(16:18:51) kr_: xiuzhi: I assume you mean the build tool ?
(16:19:06) xiuzhi: you mentioned last meeting:
(16:19:07) xiuzhi: Currently packaging and everything related is centralized scp respectively instset_ooonative ...
(16:19:07) xiuzhi: to be able split OOo and to make a "construction kit" out of it,
(16:19:07) xiuzhi: we need to distribute the infos to where they belong
(16:19:07) xiuzhi: it is more or less some trial&error until one has installed everything needed and has configure everything properly ...
(16:19:08) xiuzhi: your idea: build helper
(16:19:10) xiuzhi: a tool helping to install all prerequisites and to configure OOo for building
(16:19:12) xiuzhi: this tool could also allow to select "features", e.g. to create a product just consisting of Writer and Calc ...
(16:19:15) xiuzhi: ideally the "features" would be "advertised" by the appropriate modules, the "Writer" feature by the writer module, the "Calc" feature by the calc module etc.
(16:19:18) xiuzhi: if every module would advertise what it offers, the "tool" could collect these infos and could offer to build "products" respectively "deliverables" out of them ...
(16:19:21) xiuzhi: build conftool
(16:19:45) xiuzhi: kr_: you named the tool "build helper"
(16:20:02) kr_: yes, let's call it "build helper" :)
(16:20:05) xiuzhi: my idea:
(16:20:06) xiuzhi: + can collect and show the modules dependency tree automaticlly before building .
(16:20:06) xiuzhi: make it easier to build OOo source dump with special LinuxOS release. I found Debian and UBUTU has splitted the OOo source to parts to easier build with their OS.
(16:20:17) xiuzhi: is it possible to help to short the OOo building time and
(16:20:17) xiuzhi: support OOo online updating process by patches?
(16:20:17) xiuzhi: Need the tool has a GUI?
(16:20:22) liutao: The netbean tell me : can not find symbol:
(16:20:22) liutao: virtual_ = !prop_[i].isEmpty() && domain_.deps_[i].equals(prop_[i]);
(16:20:36) liutao: if (filter.deps_[i] == null || filter.deps_[i].isEmpty())
(16:20:48) liutao: if (path == null || path.isEmpty())
(16:20:49) liutao: .....
(16:20:59) liutao: Same errors in these lines.
(16:22:15) kr_: xiuzhi: every module needs some file (.nscp) to describe what it can deliver ... the "build helper" needs to collect these files and should offer to construct "products" and "deliverables", e.g. OOo Linux ISO, or OOo Writer Windows ISO etc.
(16:23:16) xiuzhi: kr_: agree
(16:23:17) kr_: liutao: I did export it from Netbeans, seems that this fail somehow, I will tar it by hand and send it again ...
(16:24:12) liutao: OK
(16:25:30) kr_: would it be OK for you, to close the meeting for today?
(16:25:44) liutao: ok for me.
(16:26:06) kr_: we may want to have the next one next week Tuesday, to allow Ingo to participate ...
(16:26:21) liutao: great
(16:26:34) _ch_: :)
(16:26:59) kr_: wish you a nice evening :-)
(16:27:05) kr_: bye bye ...
(16:27:13) xiuzhi: by
(16:27:22) _ch_: Have a nice day! bye :)
(16:30:34) liutao: bye