You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2005/05/12 15:55:05 UTC
[release][VOTE] Releasing MINA 0.7.1
Hi, all.
Long time has passed since first draft of MINA API is out. Now
ApacheDS 0.9 is released and MINA showed its strength as a network
application framework. I appreciate all of your support and
contribution on MINA in spite of its imperfectness. I think it is
time to release MINA officially and find out its weakness and strength
from more user feedback.
While maintaining 0.7 stream, we'll work on 0.9 to provide a new and
integrated API, and more feature-rich filters and utilities. Isn't it
exciting? ;)
Anyway, here is my +1!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Julien Vermillard <jv...@archean.fr>.
Le jeudi 12 mai 2005 à 22:55 +0900, Trustin Lee a écrit :
> Hi, all.
>
> Long time has passed since first draft of MINA API is out. Now
> ApacheDS 0.9 is released and MINA showed its strength as a network
> application framework. I appreciate all of your support and
> contribution on MINA in spite of its imperfectness. I think it is
> time to release MINA officially and find out its weakness and strength
> from more user feedback.
>
> While maintaining 0.7 stream, we'll work on 0.9 to provide a new and
> integrated API, and more feature-rich filters and utilities. Isn't it
> exciting? ;)
>
> Anyway, here is my +1!
>
> Trustin
+1 I need to release my MINA based software soon, so I'm pretty
pleased :)
Julien
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Stephane Bailliez <sb...@apache.org>.
Alex Karasulu wrote:
> 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 ;).
Having a message like "WARNING - I just changed the whole API, it's up
to you to sort out everything now" may be the minimum...but won't help
much.. except make you breath the 4 letter word another time. :)
> 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.
I agree that while a component does not reach a 1.0, public API is
subject to change anytime. During these time, we are normally still
somewhat looking for the best API, add a better semantic, etc... and
adding deprecation may add a bit of an unecessary overhead.
However when the component is part of an application it resides within,
there are extra care to take about. For sure.
> 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.
It's a bit different and the reason they did not go to the TLP route
before was apparently because they had more important things to care
about than moving everything. If you want to take an example for Tomcat,
just keep in mind that Ant and Digester for example were initially part
of the Tomcat code. As for the commons, you don't need to have the same
prerequisites than for any other project.
I think Emmanuel is right that MINA and ASN1 will ultimately probably
find a better place at commons than at Directory.
Maybe not now, but not that far from now. They both have a much wider
audience than Directory as they are components.
> 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.
>
> o a CI system that works and does not require me to know python or
> movie character names ;)
I have found BeetleJuice[1] to work quite well for now.
I installed it recently at work to monitor some projects. It takes only
a couple of minutes to setup
[1] http://www.pols.co.uk/beetlejuice/
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Alex Karasulu <ao...@bellsouth.net>.
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
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Trustin Lee <tr...@gmail.com>.
Hi Emmanuel,
2005/5/22, Emmanuel Lecharny elecharny@apache.org:
>
> 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.
Project dependencies still point to MINA-0.7.x, so it doesn't become a
problem. You can simply prebuilt JARs or build at branches/0.7. I think I
talked about this movement when I release 0.7.1. If this dismayed you, I
apologize from my heart.
> Last thing : is there a history.txt that explains the differences
> between each version? This could be very cool to have one ...
I'm using JIRA to track recent changes on a project. It is very very very
useful. It becomes really convenient when you write a release note. Please
look at MINA roadmap page.
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Emmanuel Lecharny <el...@apache.org>.
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.
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)
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 don't want to be seen as a whining, but it seems to me that this
should be avoided. 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.
I understand that odd versions are experimental ones, but IMHO they
should assume a certain amount of continuity with even versions.
Deleting classes, interfaces or public methods should be avoided, and
'deprecated' should be preferred. I know that this is something very
difficult when working on a large refactoring, but as soon as a version
as been released, then you have users, whom will see the released
version as a contract between them and us. Breaking this contract is
harmfull...
On the other side, we also can consider that MINA is a standalone
project, and that 0.9 release is necessary but don't have to be linked
with ApacheDS. ApacheDS 0.9.1 could perfectly work with MINA 0.7.1. But
don't you think that, in this case, MINA could be seen as a totally
separated project? What about creating a commons-protocolHandler
project, or whatever? Does MINA has to be a subproject of ApacheDS?
As far as I am concerned, this question will also raise for ASN.1
compiler sooner or later.
May be I'm misleading, but, whatever, it's just my opinion, after all,
and it doesn't have to be followed, I can perfectly understand than I
missed some valid points. Do not think that I want to give advices, or
whatever lessons on 'good behaviour', I'm not smart enough to do that!
And even if I'm not totally wrong, I insist : I don't blame anybody.
So, guys, tell me : did I totally missed the point?
Last thing : is there a history.txt that explains the differences
between each version? This could be very cool to have one ...
Emmanuel Lecharny
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Trustin Lee <tr...@gmail.com>.
Hi David,
2005/5/15, David Boreham <da...@bozemanpass.com>:
> -1 from me. I'd like to see the memory leaks fixed before releasing.
> In our experience the leaks in MINA make Apache DS almost
> unusable.
>
> I believe Elliot will be posting some patches that fix the bigger leaks
> soon.
OK, then let's wait for the patch first... :)
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Alex Karasulu <ao...@bellsouth.net>.
Noel J. Bergman wrote:
>Alex Karasulu wrote:
>
>
<snip/>
>>However I'd like to take this opportunity to clear up some potential
>>misunderstanding or miscommunication regarding our version numbers.
>>This release is not a stable (production grade) release. A memory leak
>>is just fine for odd minor numbered releases.
>>
>>
>
>This use of odd/even numbering to have a quality semantic may well be
>confusing to people. The HTTP server project mentions alpha, beta and GA
>releases. Jakarta projects refer to "builds", as in nightly, milestone,
>beta and Release. A "Release Build" is like a GA release. I'd suggest
>considering one of those, or something in reasonably common usage.
>
>
We actually did consider these other models from a number of
classifications. Surprisingly we were diligent this one time :) and
researched the release models before selecting one. We did not invent
this even/odd model, the Linux Kernel community did. For example, one
of several influencial peices of research we encountered, was from our
very own Justin Erenkrantz. Justin's paper[1] helped finalize our
decision to adopting the Linux Kernel model.
Even minor numbers for kernels like 1.2, 1.4, 2.2, 2.4 ... etc represent
stable kernel releases. Odd ones like the 1.3, 2.3 and 2.5 kernels
represent unstable releases of the kernel due mostly to new feature
additions. Immediately I know the stability of the kernel by its minor
release version number. The minor number is really a branch number.
Justin sites these benefits and talks about others as well in his paper.
I agree people don't immediately know off the bat which model we use.
Regardless of the release model selected, we still have to tell users
about it. It is best to stick to whatever model we have chosen and
educate users. The model makes little difference to us however
rehashing the release model once it has been chosen does cost us in
terms of enegy and confusion.
-Alex
[1]
http://www.ics.uci.edu/~wscacchi/Papers/Open-Source-Research/OSSE3-Erenkrantz.pdf
RE: [release][VOTE] Releasing MINA 0.7.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex Karasulu wrote:
> David Boreham wrote:
> > -1 from me. I'd like to see the memory leaks fixed before releasing.
Not that it applies here, but a couple of observations. Were David a PMC
member, a -1 *on code* with a technical justification would be a binding
veto of that change. On a release, it is not a veto, but consideration
should be given.
> > In our experience the leaks in MINA make Apache DS almost
> > unusable.
> However I'd like to take this opportunity to clear up some potential
> misunderstanding or miscommunication regarding our version numbers.
> This release is not a stable (production grade) release. A memory leak
> is just fine for odd minor numbered releases.
This use of odd/even numbering to have a quality semantic may well be
confusing to people. The HTTP server project mentions alpha, beta and GA
releases. Jakarta projects refer to "builds", as in nightly, milestone,
beta and Release. A "Release Build" is like a GA release. I'd suggest
considering one of those, or something in reasonably common usage.
--- Noel
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
> Alex Karasulu wrote:
>
>> Sorry could not get to this earlier due to tech difficulties...
>>
>> Anyway I think it's time for the MINA release as well: +1
>
>
> -1 from me. I'd like to see the memory leaks fixed before releasing.
> In our experience the leaks in MINA make Apache DS almost
> unusable.
>
> I believe Elliot will be posting some patches that fix the bigger
> leaks soon.
Well if its within the week let's wait.
However I'd like to take this opportunity to clear up some potential
misunderstanding or miscommunication regarding our version numbers.
This release is not a stable (production grade) release. A memory leak
is just fine for odd minor numbered releases. I know how that sounds.
Users should however be aware of the experimental nature of such
releases. So once again for the record, all releases with odd minor
numbers are experimental feature releases whereas even ones are stable
releases. The idea is to release features to the public quickly so you
get feedback faster.
IMHO this community is not releasing with enough frequency. Code that
is changing the most frequently due to new features should be releasing
the most frequently. So I completely see how users can be mislead
thinking every release is a major event even if it's on a minor number.
We need to encourage more feature releases even if performance is
suboptimal. I want to make sure this community does not get too uptight
with new feature releases. MINA especially has held back a release for
way too long. It's too good to be having its first external release
now. New features are appearing all over MINA as it evolves: we need
the greater public at large (those without svn and maven experience ;) )
to play with them and provide feedback. That's what minor releases are
all about.
If this leak was in a 0.8 then I would completely agree with your
objection. I know I'm beating a dead horse but just to be clear I want
to give another example. If 0.8 was released already and you found this
bug then we would branch the 0.8 tag and patch it with your bug fix.
Hence a 0.8.1 release would occur if the bug is really severe. I just
want to drive home the fact that once a stable release is made, no new
features are introduced in that branch: just bug fixes are.
Now back to the mem leak ... I'd like to to see the leaks gone too
especially if the problem has already been isolated and patches for a
fix are comming soon. If you can get a test case and patch into a JIRA
within the week we can hold the release until the testcase confirms the
leaks, the patch is evaluated, and applied. Otherwise let's make the
changes in another release like 0.7.2. Nothing stops us from releasing
0.7.2 a few weeks later. It's all good :).
Thanks,
Alex
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by David Boreham <da...@bozemanpass.com>.
Alex Karasulu wrote:
> Sorry could not get to this earlier due to tech difficulties...
>
> Anyway I think it's time for the MINA release as well: +1
-1 from me. I'd like to see the memory leaks fixed before releasing.
In our experience the leaks in MINA make Apache DS almost
unusable.
I believe Elliot will be posting some patches that fix the bigger leaks
soon.
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Alex Karasulu <ao...@bellsouth.net>.
Sorry could not get to this earlier due to tech difficulties...
Anyway I think it's time for the MINA release as well: +1
I can also voluteer to look at any of the zip/tar balls you create Trustin.
Great work over all.
Thanks,
Alex
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Mike Heath <el...@gmail.com>.
+1
I'm not a committer but I've been using MINA quite a bit lately and
would love to be able to develop to a stable API.
On 5/12/05, Trustin Lee <tr...@gmail.com> wrote:
> Hi, all.
>
> Long time has passed since first draft of MINA API is out. Now
> ApacheDS 0.9 is released and MINA showed its strength as a network
> application framework. I appreciate all of your support and
> contribution on MINA in spite of its imperfectness. I think it is
> time to release MINA officially and find out its weakness and strength
> from more user feedback.
>
> While maintaining 0.7 stream, we'll work on 0.9 to provide a new and
> integrated API, and more feature-rich filters and utilities. Isn't it
> exciting? ;)
>
> Anyway, here is my +1!
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
Re: [release][VOTE] Releasing MINA 0.7.1
Posted by Vinod Panicker <vi...@gmail.com>.
On 5/12/05, Trustin Lee <tr...@gmail.com> wrote:
> Hi, all.
>
--snip--
>
> Anyway, here is my +1!
my +1 too
Regards,
Vinod.