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.
I will -1 any new release until this is done, or at least, in a good
progress state, FYI.
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.
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.
Julien's question about the serial project also needs to be addressed,
otherwise, he may be disapointed.
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?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
