mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Logging filter oddity
Date Wed, 17 Jun 2009 20:54:19 GMT
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



Mime
View raw message