Trustin,
I wished you just left this thread alone. I don't want to stir anything up
so I will just point out the facts.
I'm being diligent as a concerned ASF member and part of the MINA PMC. MINA
has a young PMC that barely understands the rules. Some are missing. 90%
of the code/commits were from you in the past year. This is not healthy and
pretty close to a red line. Someone just said to me that MINA is a mock PMC
with Trustin followers. I know and hope this is not the case, but you
cannot be disappointed if at times these facts eat away at good faith.
While at Directory I've seen you panicking, thinking "I am the only MINA
committer - we don't have enough critical mass." We discussed how more
protocols using MINA will help the community but you always tried to move
codecs into MINA. At Directory you moved the LDAP ASN.1 codec into MINA and
we had to move it back. We could not release ApacheDS without pushing for a
MINA release until we broke that release dependency problem here [0].
This is a repeat offense with the HTTP codec here [1]. The first time we
just fixed the problem and you complained a bit. After realizing the
ASN.1codec is only useful for LDAP you let it go. It's a tendency you
have so it
is something that needs to be balanced to result in the right outcome. If
we can stuff it into MINA we will do that OK - I promise. Please don't take
it personally. I want community for MINA too but not at a cost to other
budding projects that are extremely susceptible. I am loud and can fight
for what is right (when I am aware something wrong is happening) but others
might not and that's my reason for intervening and pushing the present
outcome. Others might just accept the circumstances or leave.
Projects that use MINA will always have their committers coming back to
MINA. Having projects blossom to possibly graduate from MINA should not
seem threatening but uplifting. It's a good thing - it means another
success story for MINA.
More inline ...
On Jan 21, 2008 4:11 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> => The HTTP codec is *not* part of MINA core at all. We can always
> assemble it back into AsyncWeb within an hour, because it was just
> almost renaming packages of some classes since it was imported into
> sandbox. What matters is how individual components under MINA project
> are versioned, and that's why we are discussing about restructuring.
Safe-guarding these new protocol sub-projects was my aim and I achieved that
so I am satisfied. This restructuring conversation began after other threads
commenced so let's not pretend as though I missed something.
Peter's suggestion in the restructuring thread was, as usual, to diffuse
tension after seeing some storm about to brew. It's a skill Peter perfected
at Avalon; we should spare him from having to apply it here too.
Go back and reread the trail of emails on this "Was" thread to put them in
perspective before you changed the subject. If you look objectively you'll
see, first you blow off my proposal. Second even with undeniable facts you
try to "save face" as someone more senior and community conscious corrects
you. Don't feel threatened - just learn and move on. I may not be gentle,
and can be stern. Perhaps even rough especially when I feel I have to plow
through a committer with possibly several followers to amplify their
message.
So, please stop making incorrect assumptions that MINA will be another
> Jakarta or MINA will swallow existing products anymore. (yeah you
> already have stopped I guess, but I hope you don't overreact again
> later and I don't want to overreact, either.)
My assumptions are right on target (subversion and mail archives will show
this [0],[1] - more available on both points if you like).
You're displeasure in hearing my assumptions is not my problem.
When I suspect something is wrong, it will be flushed out into the open and
handled. If I make a mistake I will correct myself or stand humbly corrected
by others. I don't have the need to be right all the time. There is no
show going on for others to watch.
...
=> However, I'd like to express my disappointment on the premature
> exaggeration of the current situation of the project in this thread,
> especially considering that the community already started to discuss
> to find the solution that addresses everyone's concern. Please be
> more careful and double check your mail box before posting something
> important.
>
Was this really necessary?
SVN shows the movement of the codec from Asyncweb to the MINA subproject.
The Directory mailing list and SVN shows that you moved the ASN.1 codec
before and we had to move it back. When I suggested moving the HTTP codec
back into Asyncweb in this thread you resisted even with all those viable
points to support it. In the end the outcome was clear. Here they are
those points again. What's so accusatory about them? These are just my
thoughts about negative possibilities.
---------------
Stripping codecs out of protocol subprojects to put them into the MINA
subproject would hence:
(1) bulk up the MINA subproject while stripping many protocol servers
down to insignificant shells wrapped around MINA libraries
(2) severely impede the growth of community around separable protocols
based on the MINA API
(3) require protocol subprojects to release MINA proper whenever changes
are made to their codec interfaces
(4) turn MINA into a monolithic TLP that is hard to manage as is the
case with Jakarta
(5) force subprojects to have to participate in the MINA community while
mixing concerns: lurkers interested in one protocol will have to deal with
all messages pertaining to all codecs and MINA proper
(6) deter the genesis or migration of new protocol projects at/to MINA
if MINA cannibalizes their codecs
---------------
So when you consider these facts you'll see that my comments were not even
remotely exaggerated. I'm just remembering further back into the past and
as I said pointing out the negative possibilities.
After getting caught red handed with one hand in the cookie jar (2nd time)
don't get mad and resist. Instead do the right thing: Don't be sour. Say
sorry and put the cookie back. Otherwise a cycle of tension results.
=> We are all responsible for the IP clearance process. All PMC
> members need to learn the IP clearance process so it's taken care of
> even if the PMC chair is overwhelmed or distracted by other issues.
> Especially, if there's someone who has an experience with IP
> clearance, he or she has to do the best to mentor other PMC members,
> instead of just sitting down and looking at the clearance process
> being delayed like AsyncWeb did.
>
There are documents on how to do this. Just goto the incubator and follow
the process. One cannot plead ignorance to the legalities that the ASF must
abide by; most especially officers.
I spent countless hours arguing with the lawyers of the company that granted
Asyncweb trying to get them to realize that we cannot change the wording of
a software grant for just them. I ran out of time and could not assist you
- eventually you read the docs and did it yourself. I don't see a problem
with the Chair doing some paperwork.
...
This year, we will experience a lot of change in this project and see
> more adoption.
Hopefully! I am looking forward to a 2.0. I will commit time to helping.
I have been committing almost 90% of code recently and
> it's not the exact situation I wanted to see in 2008.
Yes, this is not healthy. We need more people in the core. If you will
help me get acquainted with the 2.0 alterations I will try my best to
contribute to maintaining the core to help balance things.
Also, it would be nice if we don't *seem* to have people vote a certain way
because you voted that way. Please keep an eye out on how big your
influence is. If you show me that you are concerned here then it's much
harder for me or anyone else to make assumptions. You have no idea of how
much of a wake you leave behind you and how that impacts this community.
One way I was taught to lessen influence was to defer my vote (in a votes I
kick off) until the end. This way others don't follow the leader in
response. It's not a strict rule at the ASF. It's a humble practice by
responsible Chairs.
-Alex
---------
[0] - http://issues.apache.org/jira/browse/DIRSERVER-738
[1] - http://svn.apache.org/viewvc?view=rev&revision=596187
