Hi, On Thu, 24 Apr 2008 12:06:57 +0200 Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi, > > I have created DIRMINA-575, set to blocker. We need better > documentation, otherwise we won't be able to get new committers to > get into the code base.
It's not just committers, it's for users too, there is some part of the project we need to fully document, specially new ones. Would be nice if we can work an precise list of things to document, so we can concentrate our efforts and follow progress easly. > > I will -1 any new release until this is done, or at least, in a good > progress state, FYI. Well is it reasonable to block milestone for doc issues ? blocking dot zero release or RC I understand, but M it's sounding a bit extreme. > > I have also some concerns about some classes which should have been > removed or deprecated. There where a convo two years ao about pooled > ByteBuffer, where we stated that it was dubious, and can be removed. > I see no reason to keep those pooled BB into the 2.0 code base, if we > have a chance to remove it before the first RC. > > I also question the need for a complete rewrite of the IoBuffer, > where an simple extension of nio.ByteBuffer could have been ok. I > will try to experiment around this. Go ahead :) The biggest issue will probably be auto expand. > > Last, not least, before getting to GA, I would like to see perf tests > to be done ( Mina / Grizzly ). We don't need to do that right now, > but some threads have expressed some interesting questions about perf > difference between Direct and Heap buffer, which need to be addressed > seriously (microbenchmarkings are just ok to get a first impression, > not to get the real numbers), and some controversy about compared > perfs of those two projects need to be clarified. For my personal use, MINA is value is more in the codec/filter stack that in the raw perfs. Even if it was 30% slower than another framework I'm not really sure to switch. The hardest point to settle is which benchmark ? On which protocol ? I think we could use the dummy echo protocol, here the gizzly example : http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.html The biggest difficulty is to fond someone with 2 machines, motivated enought for doing the test :) > > Julien's question about the serial project also needs to be > addressed, otherwise, he may be disapointed. Well I think it's going to be shorted soon I think. > > Still lot to do before going to 2.0-GA, IMHO ... > > Thanks ! > > Thanks > > "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote: > > Hi, > > > > There are currently 47 unresolved issues in our issue tracking > > system. IMO, they can be categorized into the following categories: > > > > 1) Bugs that needs fix > > > > https://issues.apache.org/jira/browse/DIRMINA-539 > > https://issues.apache.org/jira/browse/DIRMINA-574 > > > > These are known bugs so they need to be fixed before the GA release. > > > > 2) New features or improvement requests that require refactoring or > > API change > > > > https://issues.apache.org/jira/browse/DIRMINA-554 > > > > 3) Others that don't require any API change > > > > All the other issues > > > > This means we have high possibility of reaching the first RC after > > three fixes. This is a good news for many those who use 2.0.0 > > milestones. If there's no noticeable issues with the RC, we can > > proceed to the first GA release of MINA 2. > > > > After then, we can keep adding bells and whistles in 2.1, 2.2 and > > so on. > > > > The reasoning behind this idea is to give users more chance to use > > MINA 2, which is a great step-forward comparing to MINA 1, and > > eventually will lessen our burden to maintain three branches at the > > same time. > > > > WDYT? > > > >
signature.asc
Description: PGP signature
