[openi18n-im:01363] 12.2 debrief meeting irc log

Below is the irc-log of the debrief meeting.

Cheers, -Jens


09:58:57 <llch>	hi guys
09:59:16 <HidekiMPK>	Hello!
09:59:21 <llch>	let's start the debrief meeting in several minutes. who is 
online today?
09:59:24 <llch>	HidekiMPK: hi!
09:59:26 <juhp>	good morning
09:59:55 <HidekiMPK>	Good morning everybody!
10:00:34 <tagoh>	morning all
10:01:03 <kasha>	hi
10:01:31 <llim>	hi :)
10:02:04 <llch>	kasha: hi :)
10:02:18 <llch>	HidekiMPK: will ssriram able to join us today?
10:03:42 *	llch hopes ervin able to join us as well..
10:03:43 <HidekiMPK>	I am not sure... I 'll call him.
10:04:27 <llch>	no worries, we can get started first
10:05:09 <llch>	So the agenda of the meeting has two parts. first is to review 
r12.2 cycle, second we want to look forward on coming r12.4 version
10:05:35 *	yongsun ([email protected]) has joined #iiimf
10:05:51 <llch>	## Review ##
10:06:11 <llch>	in review we are going to talk about 7 points on r12.2
10:06:12 <llch>	  - Schedule
10:06:13 <llch>	  - Feedback on feature implementation
10:06:13 <llch>	  - Feedback from users on usability
10:06:13 <llch>	  - Things that we need to keep on doing
10:06:15 <llch>	  - Things that we need to improve
10:06:17 <llch>	  - QA
10:06:20 <llch>	  - Release engineering
10:06:37 <llch>	anything that needs to add on this list before we get some 
discussion going?
10:06:58 <llch>	yongsun: hi there
10:07:10 <ervin>	hi, good morning!
10:07:12 <yongsun>	Hi, llch,
10:07:20 <llch>	ervin: hey :)
10:07:45 <llch>	### Schedule
10:08:42 <llch>	around the table - let's talk about your comments on the last 
schedule in your contribution POV
10:09:37 <llch>	ervin: would you start on comment few points? does the schedule 
facilitate you?
10:11:47 <llch>	HidekiMPK: what do you think?
10:12:35 <HidekiMPK>	The scheduling of each phases and tasks associated with 
worked greatly.
10:13:14 <HidekiMPK>	It really helped aligning the tasks, although we've missed 
some of the targets.
10:13:56 <juhp>	right
10:14:01 <llch>	do anyone see the 3 months devel cycle is the right amount of 
time to push features and enough testing out?
10:14:56 <llch>	are there any indication on slipping some of the target? how 
should we improve to help that?
10:15:03 <ervin>	agree, the schedule is great that we can follow it and make 
release on time.
10:15:46 <HidekiMPK>	It was juust a right cycle, so the next cycle for r12.3 
would become pretty much like the one of r12.2.
10:17:29 <llch>	i see the biggest advantages of shorter rel cycle like 3 months 
improve our community activity on it and able to release more testing 
externally. my question to you all is - how do we able to resolve on 
implementing larger feature?
10:18:01 <juhp>	I think trying another short cycle for 12.4 is a good idea since 
we've already learnt quite a lot from the 12.2 cycle in terms of process I mean
10:18:27 <HidekiMPK>	Several check points during the development and early 
status report would help managing slippage. Having said that, everybody 
performed so great!
10:18:38 *	hwanjin ([email protected]) has joined #iiimf
10:18:55 *	hwanjin ([email protected]) has left #iiimf ("Segmentation Fault")
10:19:24 <llch>	any idea on how to deal with a feature that needs longer than 2 
months development time?
10:19:26 <tagoh>	llch: yeah, that's a problem. I'm afraid of it.
10:19:47 <juhp>	more milestones, testing and stabilization between releases 
would be ideal though in the longer term IMHO
10:20:04 <HidekiMPK>	Surely. Trying shorter cycle would be a good excercise.
10:22:02 <HidekiMPK>	Can some of the features development and testing cycle be 
bound to multiple releases? (which implies to develope the schedule/task list 
for multiple releases up front)
10:22:09 <tagoh>	IMO current release cycle is tight a bit and we were going to 
try implementing a lot in that tight schedule. without enough testing perhaps
10:23:27 <llim>	yup...i have the same feeling as tagoh
10:23:36 <llim>	testing is a bit short.
10:23:38 *	krisna ([email protected]) has joined #iiimf
10:23:46 *	krisna is now known as hwanjin
10:24:26 <llch>	HidekiMPK: break down some of the large features into smaller 
for different releases make sense. however if it is a really large feature (that 
cannot break down), the trunk has a half-implemented feature, we cannot really 
release it tho?
10:24:33 <tagoh>	HidekiMPK: it could be. like the devel release with shorter 
release cycle and the stable release with longer release cycle or so
10:25:04 <llch>	tagoh: but i am considering devel release as "beta", right?
10:25:21 <tagoh>	llch: or alpha. yes
10:25:33 <llch>	llim: in QA standpoints, what are the thoughts on testing phrase
10:26:05 <llch>	tagoh: another thing is most of the distro cannot include IIIMF 
if the release cycle is too long.
10:26:08 <tagoh>	llch: but it's not that we'd recommend to use for the end users.
10:26:25 <llch>	hwanjin: hi krisna!
10:27:19 <tagoh>	llch: any distro didn't include GNOME 2.9.x release say, did 
it? I mean something like that.
10:27:49 <hwanjin>	llch: hi :)
10:27:59 <llch>	so let's make some decision. i see many people agree on we 
should try another shorter release, so let's go ahead with this decision
10:28:16 <llim>	llch: i think the period is a bit short
10:28:27 <llim>	given the number of testers :)
10:28:34 <llch>	llim: in term of QA period? or overall period?
10:28:42 <llim>	and the scope is not as wide as I would like
10:29:04 <llim>	llch: at least a week would be ideal :)
10:29:06 <llch>	llim: can we release development beta package in middle of 
development cycle for you to QA?
10:29:35 <juhp>	I agree one week is really too short for qa and releng
10:29:48 <llim>	yup..that would be a good idea as well, i can update the 
testcase if necessary so to aviod last min rush
10:29:59 <llch>	juhp: how many days would you need for releng?
10:30:13 <llch>	llim: will take your recommendation on one week on final QA
10:30:23 <llim>	thanks :)
10:32:25 <llch>	** so the decision are: at least one week of final QA; shorter 
period still good; 3 months period are in review in term of QA and releng time.
10:32:30 <juhp>	llch: well for the 12.4 release, I was thinking it would be 
better to have releng subschedule with some RCs say
10:33:05 <ervin>	how about 3 RCs releases before announces for testing/bugfix.
10:33:28 <llch>	question on the field is: how to handle large feature in current 
cycle
10:33:41 <llch>	juhp/ervin: good suggestion. we should have some fixed amount of 
RC before gold
10:34:06 <llch>	** set # of RC before gold - juhp
10:34:07 <juhp>	ervin: 3 may be too many, I guess it also depends on the quality 
of the release
10:34:33 <llch>	** ACTION: complete r12.4 schedule - llch
10:34:43 <juhp>	some betas earlier on may be more helpful
10:35:05 <llch>	juhp: can you assist me on your take in betas and RC from releng 
POV?
10:35:20 <llch>	i will send off the r12.4 draft to you first
10:35:24 <juhp>	llch: ok
10:35:29 <llch>	great. let's move on
10:35:50 <llch>	## Feedback on feature implementation and users on usability ##
10:36:05 <llch>	couple of points that we want to talk about in these area
10:36:18 <llch>	- how to deal with feature slipage
10:36:33 <llch>	- overall feature delivery of r12.2
10:37:04 <llch>	- what did we completed, or didn't
10:37:17 <llch>	for last one i need to get some clear indication on the list so 
i can move them to r12.4
10:37:43 <HidekiMPK>	Regarding half-implemented features: A couple of options - 
blanching, keeping it in trunk but statically disabling(like #ifdef), or keeping 
it in trunk but block out with some switch if the new big feature can co-exist.
10:39:23 <llch>	good suggestion, we should have something written for this in 
our web site
10:40:08 <llch>	okay let's tick on feature in r12.2 feature list:
10:40:10 <juhp>	for gimlet I'm sorry about the poor progress I made - I 
certainly want to do better (scheduling of my work) in the coming cycle
10:40:12 <llch>	GIMLET enhancement
10:40:12 <llch>		
10:40:12 <llch>	    * UI
10:40:12 <llch>	    * Enhance the communications with IIIMF
10:40:12 <llch>	    * Applet (moves to systray to support Qt/KDE)
10:40:17 <llch>		Jens Petersen (petersen)
10:40:55 <juhp>	yea, so basically it is all not done :-/
10:41:02 <llch>	juhp: can this move to r12.4? do we need to reassign/add 
contributor on this feature?
10:41:38 <juhp>	llch: yeah I think it can be moved to 12.4
10:42:19 <juhp>	certainly more contributions would be appreciated
10:42:52 <juhp>	I think gimlet needs quite a lot of re-design and re-working
10:42:58 <llch>	HidekiMPK: should we decouple some sub-tasks. do you have any 
candidate on your side that interested on this?
10:43:34 <juhp>	I started looking at the systray - currrently gimlet assumes it 
is a gnome applet in many places
10:43:50 <juhp>	so it is some work to do
10:43:56 <llch>	any taker here want to work with jens on this GIMLET 
enhancement? this is a big usability enhancement if we do this right
10:44:23 <HidekiMPK>	Probably it is a good idea to split them into sub-tasks. 
Among them, moving it to systray would be higher priority to make it work with 
Qt/KDE.
10:45:23 <llch>	juhp: would you scope this gimlet enhancement into sub-tasks and 
seek for contributor on this area?
10:45:24 <juhp>	I think we need to think about gimlet's design on the ml and how 
to fit it tighter into iiim*cf
10:46:11 <HidekiMPK>	Right, right now, gimlet uses X transport to receive data, 
which should be fixed.
10:46:32 <juhp>	llch: ok - I'll write a mail about that
10:46:36 <llch>	** ACTION: scope gimlet for r12.4 - jens
10:46:43 <llch>	Hot Key / Toggle Key
10:46:43 <llch>		
10:46:43 <llch>	    * LE hotkey cycle switching
10:46:43 <llch>	    * Toggle Key & configurations
10:46:44 <llch>		Akira Tagoh (tagoh)
10:46:50 *	botu ([email protected]) has joined #iiimf
10:46:51 <HidekiMPK>	gimlet should directly talk to iiimd.
10:47:06 <llch>	tagoh: final status?
10:47:12 <llch>	botu: hello!
10:47:28 <llch>	Decrease footprint
10:47:28 <llch>		
10:47:28 <llch>	    * Loading LE on-demand
10:47:28 <llch>	    * Opt-out csconv until it is need
10:47:28 <llch>		Akira Tagoh (tagoh)
10:47:34 <juhp>	HidekiMPK: right - I think I need more input on how it should be 
done
10:47:40 <botu>	hello, everyone
10:48:12 <tagoh>	llch: still not supporting on iiimx and a per-user config stuff 
is also missing on r12.2.
10:48:34 <llch>	tagoh: can we push that to r12.2.1 or r12.4?
10:49:25 <tagoh>	llch: doubt it for r12.2.1 because need to add API as 
tajima-san said. so r12.4 would be better
10:49:39 <llch>	tagoh: ok
10:49:58 <llch>	** move iiimx and a per-user config stuff (hotkey) to r12.4
10:50:06 <llch>	tagoh: how about decrease footprint?
10:51:14 *	federic ([email protected]) has joined #iiimf
10:52:05 <tagoh>	can't say off hand. I need to talk about it with famao since he 
did most work for that in another branch.
10:52:41 <llch>	** ACTION: tagoh contacts famao on decrease footprint
10:53:00 <llch>	Namespace I/O API
10:53:00 <llch>		
10:53:00 <llch>		Hideki Hiura (hideki) / Sriram Swaminathan (sriram)
10:53:00 <llch>	vmseparator
10:53:00 <llch>		
10:53:02 <llch>		Motonobu Ichimura (famao)
10:53:52 <llch>	HidekiMPK: would you give us some status on these?
10:54:12 <HidekiMPK>	The basic namespace I/O API is done and in r12.2.
10:54:59 <llch>	HidekiMPK: any sub-tasks need to moves to r12.4?
10:56:32 <HidekiMPK>	configurabilities, convenient APIs for LE developpers(as 
currently it emulates POSIX I/O APIs) at least.
10:56:53 <llch>	** namespace i/o api on r12.4: onfigurabilities, convenient APIs 
for LE developpers(as currently it emulates POSIX I/O
10:56:55 <llch>	                   APIs)
10:57:22 <llch>	onfigurabilities, convenient APIs for LE developpers(as 
currently it emulates POSIX I/O
10:57:30 <llch>	Filename namescape
10:57:30 <llch>		Changing to a better naming scheme for filenames & directories
10:57:30 <llch>		Ashizawa Kazunori (kasha)
10:57:30 <llch>		Single iiim server for clients on single X desktop 	Ashizawa 
Kazunori (kasha)
10:57:30 <llch>	User server enhancement
10:57:32 <llch>		Enhance iiim server on private user mode
10:57:35 <llch>		Ashizawa Kazunori (kasha)
10:58:29 <kasha>	pathname change - done
10:58:42 <kasha>	private user mode - done
10:59:07 <llch>	kasha: shall we move "Single iiim server for clients on single X 
desktop" to r12.4?
10:59:08 <kasha>	but single iiim server for clients on single X desktop is not 
touched at all
11:00:00 <kasha>	yes.
11:00:26 <llch>	** move "Single iiim server for clients on single X desktop" to 
12.4 feature proposal
11:00:35 <llch>	IIIMQCF
11:00:36 <llch>		
11:00:36 <llch>		Gavin Tu (gavin)
11:00:36 <llch>	Common GUI Framework
11:00:36 <llch>		
11:00:38 <llch>		Toshi Tajima (tajima) / Ervin Yan (ervin) / Phill Zhang (phill)
11:01:39 <botu>	currently, QCF provide default preedit/lookup window, aux 
launcher is OK.
11:02:05 <botu>	but, QCF has some bugs needed to be fixed
11:02:54 <llch>	botu: sure, if this is only bug, then i will just tag the 
current iiimqcf bug to be must fix in r12.4. any new features that IIIMQCF needs?
11:02:56 <botu>	Also, need communicate with gimlet, currently this feather is 
missing
11:03:09 <llch>	okay this is a feature
11:03:26 <llch>	** add IIIMQCF communicate with gimlet to r12.4 proposal
11:03:41 <botu>	for Ja, QCF should support Caret position
11:03:47 <HidekiMPK>	But once gimlet start taling to iiimd directly, each *CF 
does not have to talk to gimlet...
11:04:23 <tagoh>	also need to take care of the status window too?
11:04:44 <llch>	HidekiMPK: okay so i should put: ** or gimlet talk to iiimd to 
r12.4 proposal as well
11:05:08 <HidekiMPK>	Sounds good!
11:05:10 <botu>	tagoh: you mean this status window at bottom-left of client 
application
11:05:32 <tagoh>	llch: I think what QCF is lacking is that no X transport stuff
11:05:57 <tagoh>	botu: right
11:06:15 <llch>	ervin/federic: are we go around and move common GUI to library 
level for r12.4
11:06:17 <llch>	?
11:06:43 <juhp>	HidekiMPK: right
11:06:45 <botu>	tagoh: if status infomation can be displayed on the gimlet, do 
we need this status window on bottom-left of client appcliation?
11:06:46 <llch>	** possible bug/feature: QCF adds X transport
11:07:24 <tagoh>	botu: don't assume that people always has gimlet.
11:07:34 <botu>	llch: what does mean "X transport stuff"? I'm not sure it.
11:08:04 <juhp>	botu: once gimlet speaks iiimp it is probably not needed
11:08:20 <juhp>	botu: but basically just updating some X atoms
11:08:21 <botu>	tagoh: ^-^, thanks.
11:08:47 <yongsun>	Hi, botu, I think we also need remove the dependencies of 
glib from QCF
11:09:02 <juhp>	botu: for example in Fedora Core status is not displayed in 
gimlet by default
11:10:07 <llch>	IIIMECF updates
11:10:07 <llch>		
11:10:07 <llch>		Hitoshi Miura (miura)
11:10:07 <llch>	IIIMECF emacs22 port
11:10:07 <llch>		
11:10:09 <llch>		Taichi Kawabata (batta)
11:10:12 <llch>	Documentations
11:10:14 <llch>		
11:10:17 <llch>	    * IMProtocol.spec
11:10:19 <llch>	    * LEIF.doc
11:10:22 <llch>		Sriram Swaminathan (sriram)
11:11:55 <llch>	juhp: do you know about status on IIIMECF part?
11:12:38 <HidekiMPK>	There has been a significant improvements in IIIMECF.
11:12:45 <juhp>	not so much on implementation side - but I have done some testing :)
11:13:07 <llch>	HidekiMPK: are there still some leftover to move to r12.4?
11:13:33 <juhp>	HidekiMPK: right though there still seem to be quite a lot of 
bugs left :)
11:13:46 <juhp>	or new bugs perhaps
11:14:47 <HidekiMPK>	I think so...I don't recall everything, but still many to 
go. I'll ask Taichi to report. He continued improving IIIMECF during Golden 
week, so he must have things to report :-).
11:15:04 <HidekiMPK>	Yup, new bugs :-).
11:16:01 <HidekiMPK>	Documentations should be carried over.....has been done a 
little improvement only in r12.2.
11:16:33 <llch>	** carry documentation over to r12.4
11:17:01 <llch>	okay thanks guys. i will post the proposal list to mailing list 
along with the schedule
11:17:17 <llch>	## QA and release engineering ##
11:17:39 <llch>	juhp / llim: anything else on this part?
11:18:02 <llch>	HidekiMPK: do you still able to find some people who interest on QA?
11:18:27 <llch>	we have surely lacked some testers on r12.2
11:18:34 <juhp>	we already talked a little about it earlier
11:18:57 <llim>	llch: as mentioned earlier, longer time and more testers will be 
really cool
11:19:25 <HidekiMPK>	Sure! I'll ask our QA groups.
11:19:29 <juhp>	I guess if we can spread some betas/rc1 over the devel cycle - 
then a week or two for final qa/releng is ok
11:19:41 <juhp>	s/rc1/rc's/
11:19:42 <llim>	true
11:19:52 <llim>	if we have interim release that's ok
11:20:41 <llch>	juhp / llim: are you two still comfortable on taking the rel-eng 
and QA lead?
11:20:56 <juhp>	at least for this release the one week, which also included some 
holidays was too short imo
11:20:57 <llim>	sure, as long as my service is required :)
11:22:25 <juhp>	ok for me - as long as we add more releng milestones in the 
schedule this time
11:23:24 <llch>	sure
11:23:45 <juhp>	all: if you have more feedback or input, then please let us hear :)
11:24:48 <llch>	In summary, i would like to congratulate all of your work in 
r12.2. It is definitely a very good release.
11:24:59 <llim>	do we need to have a benchmark??
11:25:11 <juhp>	does anyone find the bootstrapped tarball an improvement btw?
11:25:22 <llim>	say 80% or 85% and above to be allowed to be declared final
11:27:11 <llch>	llim: my suggestion is depends on number of MUSTFIX bugs at large
11:27:41 <llim>	ok
11:28:29 <ervin>	llch, I think we need "http://www.openi18n.org/download" for 
end user to easyly find the downloadable packages or sources.
11:29:05 <llch>	ervin: yup, you are right.
11:29:31 <juhp>	that should come under website redesign :)
11:30:03 <llch>	that remind me i need to talk with hideki on this topic :) 
anyway, let's move on
11:30:13 <llch>	## Looking forward ##
11:30:25 <llch>	  - Tools
11:30:25 <llch>	    - Wiki
11:30:25 <llch>	    - Bugzilla
11:30:39 <llch>	Tools - we have wiki in place. does anyone find it useful?
11:31:41 <juhp>	ah - speaking of the wiki I quite forgot to mention about 
relnotes... ;-)
11:31:53 <llch>	juhp: go ahead
11:31:59 <tagoh>	llch: depends on current CSS. wiki itself is no problem. but 
looks after that is a problem.
11:32:16 <llch>	tagoh: okay, that's web site redesign too ;)
11:32:20 <juhp>	I guess relnotes needs to go into the schedule if we want them...
11:32:42 <juhp>	tagoh: which problem?
11:33:21 <juhp>	but what is the best way to write the relnotes or NEWS for the 
release
11:33:26 <tagoh>	juhp: too small font, unexpected color agaist current CSS etc
11:34:00 <juhp>	should the relnotes/news just be a file in svn?
11:34:09 <juhp>	tagoh: ah
11:34:41 <llch>	juhp: i agree, that would be easy for contributors to write on 
the release notes. what do other think?
11:34:55 <juhp>	also we should announce the release a little wider than just the 
openi18n-im list...
11:35:13 <llch>	release notes will be something that need to be documented (like 
major changes on features that need to be documented for user)
11:35:26 <llch>	but something that not yet able to put it in a offical documentation
11:36:04 <juhp>	I think the NEWS file in emacs for example is a pretty good model
11:36:14 <llch>	HidekiMPK: are there any technical writer on your side who 
interested on IIIMF (for documentation)? ;)
11:36:19 <juhp>	don't know how many of you are familiar with that?
11:36:29 <llch>	but yeah release notes should be written by contributors
11:37:53 <juhp>	is there any interest in having relnotes? :)
11:40:14 <llch>	juhp: i think it will be benefit to end-user
11:40:53 <ervin>	we need also keep posting these informations on some linux 
forums. :-)  we are so shy compared with James Su.
11:41:42 <juhp>	if iiimf is going to be a real FOSS project we need to work on 
getting better documentation in place - to be it easier for people to contribute 
- relnotes seem to be a small first step in PR and docs
11:41:48 <juhp>	ervin: nod
11:41:55 <llch>	ervin: community engagement, right. i see your posts on your 
blog. can you take the initative on improve community engagement for IIIMF?
11:42:17 <llch>	ervin: can you brainstorm couple of ways on how to improve that 
and we can follow your lead?
11:43:14 <llch>	juhp: good point
11:43:45 <llch>	juhp: let's drop release-notes into Documentation "feature" part 
in posposal
11:43:57 <juhp>	ok
11:44:32 <botu>	I suggest we provide rpm pkgs to download on openi18n.net.
11:44:33 <llch>	- Bugzilla
11:44:55 <botu>	it's hard for users to build pkgs from tarball.
11:45:05 <llch>	i remember federic had built some packages for suse isn't it?
11:45:28 <llch>	i think juhp / tagoh can provide rpm from RH - what do you think 
juhp/tagoh?
11:46:00 <juhp>	llch: for the last Fedora Core release?
11:46:24 <juhp>	botu: you mean devel snapshots?
11:46:35 <llch>	juhp: i would say Fedora Core development first, and depends on 
the workload, last Fedora Core rel
11:46:47 <botu>	llch: yeah.  A peopel from Mandrake spend a lot of time to build 
pkg for mandrake from tar ball
11:46:52 <tagoh>	llch: we could put them onto there. but I don't see any good 
reason once most distros has a way to get the packages without downloading it 
with browser or so.
11:47:34 <llch>	tagoh: do you mean that because for example Fedora already have 
yum to update IIIMF?
11:47:44 <tagoh>	llch: right
11:47:52 <juhp>	llch: right - well builds for FC devel are usually in devel 
anyway - so there doesn't seem so much point in duplicating them at openi18n.org
11:48:06 <llch>	botu: the problem is, the package built in Fedora does not mean 
it can be build on Mandrake
11:48:28 <llch>	juhp/tagoh: good point. we should provide them the instruction 
on doing so then
11:49:04 <llch>	beta version of IIIMF for latest public final release? how 
benefit is it?
11:49:36 <juhp>	llch: useful it get more testers I suppose
11:49:54 <juhp>	if we publicize it
11:50:15 <llch>	okay
11:50:17 <llim>	where would be a nice place??
11:50:29 <llch>	llim: openi18n.org? :)
11:50:35 <juhp>	llch: but as you say it is a matter of time too...
11:51:19 <ssriram>	hi guys
11:51:22 <llch>	okay keep this in mind. we cannot resolve some of the problem if 
we does not have enough crowd
11:51:27 <llch>	ssriram: hi!
11:51:40 <llch>	let's move on
11:51:42 <llch>	    - Bugzilla
11:52:05 <llch>	for bugzilla, once it is in place. i am planning to move all 
feature request and bugs to there
11:52:24 <llch>	that way we will have more structured way of feature request 
among our group, and also from external
11:52:44 <llch>	for bugs we need to encourage all of the testers to report in 
bug tracking system *only*
11:53:04 <llch>	information in mailing list  will easily get lost
11:53:45 <llch>	so for any testers reporting bugs in mailing list. after initial 
dicsussion, let's ask them to submit it in bug tracking system
11:53:54 <ervin>	llch, you mean you will setup "http://bugzilla.openi18n.org", 
right?
11:54:18 <llch>	ervin: yeah, or www.openi18n.org/bugzilla/ whatever the 
directory name is
11:54:29 <llch>	llim: your status on bugzilla migration?
11:54:46 <ervin>	oh, that's great.
11:54:56 <llim>	llch: good, I have one set up on my test machine
11:54:58 <llch>	ervin: bugzilla should have richer feature for us to keep track 
of both features and bugs and handling multiple contacts
11:55:16 <tagoh>	ah, just reminds me if we have any web interface to look at the 
archive on the mailing list, but anyway
11:55:28 <llim>	will a bit more testing on the DB backup and restore, it should 
be rolling
11:55:37 <llch>	tagoh: that's another todo of llim :) mailman migration :)
11:55:45 <tagoh>	aha
11:55:47 <llim>	ETA: Friday
11:55:53 <llch>	llim: wonderful news
11:56:13 <llim>	ah yes....Mailman will be next...i got stuck cos I dont know the 
name of mailserver :p
11:56:35 <llch>	anyone cool on this? we want to have most of the information 
that need to record away from mailing list so that we won't lose any information
11:57:09 <llch>	so we need to push those content to bugzilla, web content, wiki, svn
11:57:41 <llch>	then visitors/users will able to easily find information they need
11:57:53 <ssriram>	this will be very useful :)
11:58:15 <llch>	great!
11:58:17 <llch>	  - r12.2.1
11:58:17 <llch>	  - r12.4
11:58:17 <llch>	    - Kick start on initial feature planning
11:58:29 <llch>	final agenda
11:58:59 <llch>	we need to finalise our proposal this week, so that we can move 
forward on the schedule
11:59:45 <llch>	for next release, we will call it as r12.4 (to use r12.3 (odd 
minor number) for beta release). everyone cool on this?
11:59:59 <llim>	yup
12:00:48 <llch>	for r12.2.1, we want to fix any important bugs that is leftover 
on r12.2
12:01:40 <llch>	it will have shorter release and less QA on this. all we want is 
to provide a more official tarball with fixes for distro and users
12:02:14 <llch>	for r12.4, i will send off the proposal this week and let you 
all review
12:02:44 <llch>	the important thing is if you have know people that interested 
on IIIMF. invite them to be one of the contributor
12:03:05 <llch>	hwanjin: are you interested on improving hangulLE on r12.4? :)
12:03:47 <llch>	i will also start another email for discussion on r12.4 feature 
discussion. so let's get some thinking going
12:04:37 <llch>	any other things need to discuss/comments?
12:05:00 <juhp>	is it a good time to talk about features now?
12:05:21 <llch>	if no objection, can someone able to grab this meeting log and 
post it to mailing list and wiki?
12:05:58 <llch>	juhp: yup, then let's talk about features after this debrief 
meeting is closed
12:06:53 <juhp>	llch: I can do that if noone else wants to take it :)
12:07:36 <llch>	juhp: thank you
12:08:04 <llch>	## MEETING CLOSED ## and let r12.4 begin