directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [release][VOTE] Releasing MINA 0.7.1
Date Sun, 22 May 2005 15:12:05 GMT
Emmanuel Lecharny wrote:

>Sorry that I missed the vote - holidays ...-. Now I'm back, and I don't
>feel very comfortable with some little things. Please do NOT take any of
>these comments personally, this is not what I have in mind.
>  
>
No constructive criticism is always encourage you are doing good :).

>First, I have to say that MINA is a great piece of work, and deserve a
>big BRAVO. It helps ApacheDS  to be usable, as some tests done two
>months ago demonstrate it (I've lost the mails, but they can be found
>easily. What I remember is that over 100K simultaneous connection could
>be managed with MINA)
>  
>
+1

>Nevertheless, some issues occured with the 0.7 -> 0.9 switch. Mainly,
>other ApacheDS subprojects (all the ApacheDS protocol providers) were
>brokken, due to some class being renamed or deleted (ProtocolProvider,
>ProtocolHandler, and so on). Nothing serious, but time consuming.
>  
>
I think they were fixed though before hand.  I know because I fixed 
these personally while spouting 4 letter words under my breath as I did 
so.  I did this in several places after finding the build was broken and 
not only because of MINA.  There were several other things that were 
messed up.  Too many people here feel like they own the code they work 
on.  That's where these problems are coming from.  Hard habits to break 
and human ones that do not make us bad people.  We just have some more 
of the Apache way to learn even though we are out of the incubator.

Yah it stunk big time that we have these faults but its all of us at 
different times.  We must make sure projects compile in their trunks 
regularly and if it does not in a release then we should not be here at 
the ASF.  This is the minimum requirement.

>I don't want to be seen as a whining, but it seems to me that this
>should be avoided. 
>
No you are not whining!  Please don't feel like anyone is going to haze 
ya.  Its a wise thing to do.  If you are working on a project within 
this community that affects others you should make sure you are not 
breaking code in other projects.  Or at least drop a big [WARNING] email 
onto the list.  That goes for all of us.  This is the minimum I would 
expect.  Better yet just make the necessary fixes to the 
protocol-providers really quick - but MINA committers are not obliged to 
do this.  The [WARNING] is enough. We need projects to compile one way 
or another just so we don't get caught with our pants down ;).

However note that releasing MINA should not be contingent on wether or 
not a protocol-provider works within its trunk.  That means we need to 
fix the p-p.  At this point we can start depending on the last stable 
release before we upgrade our dependent projects.  Or just learn how to 
take a timestamped SNAPSHOT which has very different semantics in Mave.  
I do not want to hold the MINA folks back from changing the API even if 
those changes are dramatic before a 1.0 is released.  If a 1.0 is out I 
would expect smooth, gentle deprecation as is expected of a mature API.

So IMHO I don't believe in deprication when it comes to sub 1.0 APIs.  I 
think they could fly by the seat of their pants giving us surprises if 
they need to.  Yah MINA people can yank stuff or put new stuff in 
without having to consider breakage or deprecation.  It's up to the 
users to take *time stamped* SNAPSHOTs if they do not want surprises or 
to stick to a stable release.

Regardless this is just my opinion Emmanuel .. I may be smoking too much 
of my hooka these days :-).  It is a radical point of view point I know. 

>I know that from time to time, it's a must to
>deliver, even if it's not perfect, because it is a good thing to have
>users and feedbacks. But I think that we are the first users here in
>ApacheDS community, and we must at least insure that the deliveries does
>not break the base code.
>  
>
+1 but it was fixed at least in some p-p - I think your copy may have 
been old.  I know it was fixed in the protocol-providers needed for the 
release at a minimum because I had to fix it myself.

<snip/>
 

>As far as I am concerned, this question will also raise for ASN.1
>compiler sooner or later. 
>  
>
This is a can of worms for which I am not ready to deal with right now.  
I can't code and deal with beaurocracy at the same time.  When the time 
is right we can allocate energies to get these projects the escape 
velocity they need.  Plus if they escape Directory I don't think I 
necessarily think the ASF would gain by putting them under a Jakarta.  
I'm inviting the bearocrats to talk I better drop the subject but with 
one last comment...

Understand that Directory is not another level of the incubator to 
graduate from.  However at the same time we must balance this with the 
fact these projects actually are distinct although needed by directory 
services.  They can exist on their own if the community and product 
matures enough.  Look at Tomcat.  Only within the past month has it 
asked to go the route of TLP instead of staying in the massive Jakarta TLP.

Let's just keep working hard to make everything better.  Good things 
will happen both for the projects here and the foundation naturally 
without forcing a fit.  The ASF leadership will always try to do what is 
best to foster the best circumstances for both the foundation and 
individual projects.

<snip/>

>it's just my opinion, after all,
>and it doesn't have to be followed,
>
...

> Do not think that I want to give advices, or
>whatever lessons on 'good behaviour', I'm not smart enough to do that!
>  
>
You're doing just fine Emmanuel .. this is the duty of a model citizen 
here: don't doubt your instincts.  I think you make some good points 
even though I may repectfully disagree on some.  These points and 
differences however arise from subtle conflicts and may be solved in 
many ways.  I think the solutions rest with ...

 o better attempts to inform with *WARNINGS* on list
 o a CI system that works and does not require me to know python or 
movie character names ;)
 o better understanding of what Maven time based snapshot semantics are 
besides using moving snapshots
 o less sense of code ownership - every line of code at directory 
reflects on us all
 o a tighter waist band on our underwear or suspenders

Ok the last one may not be necessary if the first 3 are met :).

>And even if I'm not totally wrong, I insist : I don't blame anybody.
>  
>
No worries we need tougher skins on this project.  It's ok to say 
something is not right. 

>So, guys, tell me : did I totally missed the point? 
>  
>
No you're good and I'm glad you are pushing it.  If it persists keep 
slaping our peepees.  No need for the disclaimers either :-).

>Last thing : is there a history.txt that explains the differences
>between each version? This could be very cool to have one ...
>  
>
Yah like a change log or something?

We need that.  I've done that with apacheds here ...

http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/CHANGES.txt?rev=169181&view=markup

But I have slacked off with other projects like ASN.1 and the common 
stuff.  I guess this is because we have not done external releases on 
these just yet.  I need to be more diligent.

Sincerely Emmanuel these constructive comments do us a great service and 
I thank you for having the fortitude to put your neck out and making a 
stance.  We need more of this from everyone.

Thanks,
Alex


Mime
View raw message