mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Webb" <elihusma...@gmail.com>
Subject Re: [About the Filter Chain] Proposals
Date Mon, 03 Nov 2008 15:40:30 GMT
So then we should stop with milestone releases and start pulling code
apart and start fixing it.  I am also using 2.0 in near-production
systems, but if it takes a few more months for a release, I may be
stuck with reverting back to 1.1 since I cannot release my system with
beta software in it.  I am sure that I am not the only person in this
situation.




On Mon, Nov 3, 2008 at 10:30 AM, Julien Vermillard
<jvermillard@archean.fr> wrote:
> 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