boB Gage wrote:
Emmanuel, you're right.... I should be annoyed at the previous
designer that tied our non-volunteer project with strictly defined
deadlines to a volunteer-developed library tool set; not at the
volunteers who never actually committed to support anything.
well, it's always the same story : even if you have selected a close
source API, even if you have paid a huge amount of money for it, it
could still contain bugs, and you could still be stuck.
We are really trying to do our best to deliver the best quality
software, and it's not easy. Julien, for instance, is using MINA with
the serial layer (he coded it) for its own usage. Obviously, he is ready
to pay the price for it (ie, time on his own hours), not only because he
needs it, but also because he sees the immediate benefits he can get
from such a piece of software : a community around it which can help if
he gets stuck in some part of the code.
If I can send a message to all the users : it's really easy, and
rewarding, to become a committer. It's a matter of participating by
providing patches.
Also note that we never spread the wrong signal that MINA 2.0 was ready.
It's still a milestone, and designed as unstable. Yes, I know, it takes
forever to get a release out...
Problem is I've got umpteen different things that have to be fixed and
added at our level of the application and this is neither the first,
nor even the only active issue in our code likely caused by Mina.
I've hesitated to mention the other active issue, so as to not muddy
the waters -- one problem at a time. :-)
Well, sometime, it's better to get the whole picture :)
Unfortunately, I don't think the designer who decided on Mina realized
that we were taking it places it apparently has never been before...
What we needed was a cross-platform answer to a serial application;
the tool he chose was Mina, whose serial-side is apparently new and
I'm finding not overly bug-free. Our application is being used in a
health care setting so should be as bullet-proof as possible.
This is what we are targetting too. A slipery path, too...
I'll have to ask my bosses about patches. It's really two
questions. Do they want to pay me to fix Mina library? If so, are
they willing to then give away those fixes to the community at large?
I'm on someone else's payroll, so I don't make those decisions.
You have two options here :
- you can fork MINA, if for any legal reasons you can't or don't want to
share the patches,
- or you can grant the patches to The ASF
I understand that's not as simple as willing to contribute to the project.
boB
PS... Okay, so say I do have to dig and fix this myself. How
would I confirm my Mina svn repository matches the M4 code I'm using
before I muck around with it? Or do I have to update to the latest
Mina code first? (M2 to M4 got ugly; M4 to M5 looked horrible and
was quickly reversed, been waiting for the real release ever since)
Let be clear : M4 sucks, M5 is even worst. M6 is way better. Trunk will
be (hopefully) even better. In any case, you can pick the milestone you
prefer, in the tags/ directory : it's frozen. When you would like to
move to a more recent version (say, M7 when ready), it's just a matter
to merge your modification into the trunk. as we aren't modifying the
code a lot atm (we are just in bug fix mode), that should not be a problem.
Hope it helps (a bit ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
