I agree with Rana here. And another thing... There are people who are more interested in "develop smth" then "fix smth". And to catch such kind of peolpe TODO list in WIKI is much better then JIRA.
Just IMHO :) SY, Alexey 2006/11/2, Rana Dasgupta <[EMAIL PROTECTED]>:
They serve different purposes. The Wiki is just a broad reminder to even a visitor to Harmony of what remains to be done. I think that the JIRA is more specific, maybe even more technical. The TODO page as it is today, with sublinks, also seems well suited to capture this info. But it's not a big deal. On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > Rana Dasgupta wrote: > > No problem with them being both on the Wiki and the JIRA, I think. > > Other than getting out of sync.... it just makes sense to use the > "issue tracking system" for... "issue tracking" :) > > geir > > > > > > On 02 Nov 2006 17:57:29 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote: > >> > >> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> > Alexey Varlamov wrote: > >> > > 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > >> > >> Put them in as JIRAs > >> > > Done: HARMONY-2051, 2052, 2053. > >> > > >> > Thanks - that just makes it easy for people to grab them and get > >> going... > >> > >> maybe, put the list of JIRAs on wiki? > >> > >> > > > >> > >> Alexey Varlamov wrote: > >> > >> > Below is a list of isolated development tasks which do not > require > >> > >> > advanced knowledge of VM and could be a nice start for newbies > to > >> get > >> > >> > acquainted with the code. All items are targeted for better code > >> > >> > sharing. > >> > >> > > >> > >> > 1) Eliminate duplicate implementation of j.l.Runtime.Process in > >> kernel > >> > >> > classes of DRLVM [1]. The classlib provides neat portlib-based > >> > >> > reference implementation [2], which should be reused. These 2 > >> impls > >> > >> > are roughly identical, so one needs to made more scrupulous > >> comparison > >> > >> > and squeeze some features/fixes of [1] which may be missing in > >> [2], > >> > >> > then employ [2] in j.l.Runtime of DRLVM and drop [1]. > >> > >> > > >> > >> > 2) Improve/re-implement a parser of generic signatures in DRLVM > >> kernel > >> > >> > classes [3], and move this functionality to classlib (luni ?), > so > >> > >> > other VMs could reuse it for 1.5 support. The current impl is > >> somewhat > >> > >> > messy and half-baked, one need to invent more shaped and modular > >> API > >> > >> > to the parser. One more possible issue is parser's dependency on > >> > >> > antlr, which may be considered overkill for this duty. I think > >> antlr > >> > >> > has its pros, like more illustrative code with clear > >> correlation to > >> > >> > formal grammar [4]; unfortunately this is not the case with the > >> impl > >> > >> > in question. OTOH minimizing number of dependencies for VM is > >> always > >> > >> > good. > >> > >> > > >> > >> > 3) Classlib's j.u.TimeZone expects "user.timezone" property > value > >> > >> > initialized during VM startup (BTW I did not find explicit > >> statement > >> > >> > in VMI docs for that, only indirect reference in kernel stub for > >> > >> > j.l.System). I believe this action should be done by hyluni > >> natives > >> > >> > during JNI_OnLoad, no reason to burden VM with it. Therefore I > >> suggest > >> > >> > to move "port_user_timezone()" function [5] from DRLVM to > classlib > >> > >> > (luni/port), and fix DRLVM & hyluni accordingly. > >> > >> > > >> > >> > [1] > >> > >> > >> working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java > >> > >> > + > >> working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp > >> > >> > [2] > >> > >> > > >> > >> > >> > working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\* > >> > >> > >> > > >> > >> > + > >> working_classlib\modules\luni\src\main\native\luni\shared\process.c > >> > >> > [3] > >> > >> > > >> > >> > >> > working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\** > >> > >> > >> > > >> > >> > [4] > >> > >> > > >> > >> > >> > http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf > >> > >> > >> > Para 4.4.4 > >> > >> > [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c > >> > >> > > >> > >> > Comments? Should I put this somewhere on the Wiki? > >> > >> > > >> > >> > >> > > > >> > > >> > >> -- > >> Egor Pasko, Intel Managed Runtime Division > >> > >> > > >
