mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@archean.fr>
Subject Re: [About the Filter Chain] Proposals
Date Mon, 03 Nov 2008 15:30:59 GMT
On Mon, 3 Nov 2008 10:13:07 -0500
"Mark Webb" <elihusmails@gmail.com> wrote:

> I think we should focus on getting 2.0 out the door.  We have been
> working on it long enough and I think there are many people using it
> in production or near-production systems.  Once we release, we will
> probably get alot more feedback and can use that feedback to
> enhance/fix the next version.  I would think that we should move right
> towards 3.0.
> 
> As we get closer and closer to a release, I think the API should not
> change and therefore we should not be adding functionality into the
> system unless something is really broke.
> 
> just my $.02
> Mark

Here my point of view on the subject.

Actually the MINA core code doubled since 1.1 and is quite
difficult to understand. you need to be aware, that if you release 2.0,
there is good chance it'll be hardly maintained because all the internal
code is clumsy, and hard to debug.

So until deciphering core isn't done (I think Emmanuel will succes) and
we gather a good knowledge we can't release.

If fixing a bit the monster is breaking some API I'm ready to pay the
price, and I'm actually running M3 in prod.

If we don't fix some issues like sentMessage, FilterChain and overall
internal documentation, you better be prepared to see this code rot.

> 
> 
> On Mon, Nov 3, 2008 at 10:06 AM, Emmanuel Lecharny
> <elecharny@gmail.com> wrote:
> > Mark Webb wrote:
> >>
> >> I agree that we should not 'slaughter' the current code since we
> >> are getting close to a final 2.0 release.
> >>
> >
> > This is something we have to discuss. Here, IMHO, we have two
> > options, both have pros and cons :
> >
> > 1) go as far as needed to get a MINA 2.0 with as much cleaning as
> > needed. 2) Release MINA 2.0 as fast as possible, fixing the most
> > obvious bugs, and move directly to a MINA 3.0
> >
> > Option (1) pros :
> > - as MINA 2.0 API is not stabilized yet (we are still working on
> > milestone), this let use the opportunity to do those changes with a
> > minimal harm
> > - we can do that now, not waiting for a 2.0 release to be done in,
> > say, 2 months
> > - this is the perfect opportunity to clean up the code, add the
> > missing documentation, and delivering a much better release
> >
> > Option (1) cons :
> > - it will takes months before we can release a long waited new
> > release
> > - many users are already using mina 2.0, and they will be unpleased
> > if we change a lot of things into it
> > - we have to be careful not to remove any of the existing
> > functionalities, something we don't have to take care for a 3.0
> > branch, as it won't be used in production before quite a long time
> >
> > Option (2) pros :
> > - freedom ! No need to care about the existing code, we can even
> > start from a white page.
> > - the community can grow faster, as we may have people who are
> > reluctant to enter the project while it's in a pre-release state
> > - we are not limited in time. 2.0 is expected sooner or later, with
> > a 3.0, we have more than a year to get something done
> >
> > Option (2) cons :
> > - we will have to maintain a 2.0 version which is far from being
> > perfect
> > - 2.0 seems to be slow, compared to other framework. Not that
> > important IMHO, but releasing a dog is not the perfect way to get
> > some good reports...
> > - people who are expecting a better MINA (a simpler one) might wait
> > for one more year until 3.0 is out. Even worse, they can run away...
> >
> > Of course, I'm just dumping some of the ideas I have about that.
> > atm, I have not yet set my mind on which option is the best, but we
> > can still work with both options in mind, as soon as what we do is
> > done in a branch. Soon, we will be able to decide if we release a
> > 2.0 with or without those modifications, and then merge the branch
> > into trunk or create a new version, closing the 2.0 branch (ie : it
> > will become a release branch).
> >
> > In any case, there is something very important : the current code
> > base is not known by a lot of people, and it will take time to
> > build a new community around the core code base. The biggest
> > question is : will we find enough people wanting to work on the
> > current trunk in order to get the new release (be it 2.0 or 3.0) ?
> > And how long will they be dedicated ? What if we release a 2.0-RC
> > in the next few months and as we don't have anyone wanting to start
> > a 3.0 ?
> >
> > so, now, wdyt ?
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel L├ęcharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >

Mime
View raw message