Jeremy Hughes wrote:
AFAIK Apache in general does not have a policy to handle this kind of
situations.
Yes, it does. It's the Apache Incubator.
There is also the option of a software grant to an existing project. This
was done for a new version of Muse (WS-Management stuff; can't remember
the details) from IBM around an year ago.
Another option would have been to start a revolutionary branch in
Apache SVN after -dev list discussions on the issues with Sandesha2 /
SMTP. Then Mercury's development from scratch would have been in full
view of the Sandesha2 community from the start.
+1 .. in 20/20 hindsight I totally agree with you that'd have been a MUCH
better way to have done this :(.
That would imply a new project, seeded with a contribution from a
third party, so should go through the incubator. There are good
reasons for this - e.g. name checking the name 'Mercury'. If a
separate project is what people want, we should *at least* have the
discussion with the Incubator PMC / general list on whether an
incubator podling is required. I feel uncomfortable starting a new WS
subproject seeded with a relatively large body of code that wasn't
developed at Apache, without it going through the rigor that the
incubator brings.
Fair enough.
My preference though would be that we don't have a fork and that there
is either a clear distinction between the goals of Mercury vs
Sandesha2, or even better a combined project with perhaps multiple
modules.
I think Jaliya's measurements show that Mercury is not a done-deal
project. Maybe the right thing to do is start a variation of Mercury in
Apache as a "revolutionary fork" and really combine the two effectively.
The fundamental difference is that Mercury is based on a state machine
model and that appears to be a better architectural approach doing an RM
implementation than the approach in Sandesha2.
That said, there are many areas of Mercury that still require serious
work: threading model, transactions, persistence model etc.. Maybe if we
combine the two and do a new version of Sandesha that'll be better all
around. That is, use Mercury as a source of ideas and code but not
continue "Mercury" in ASF but rather start a new effort to cut-n-paste
stuff from wherever and get a damned good RM impl out to our users.
Mercury can remain in wso2.org and we can EOL as the new one comes up and
starts working properly.
Thoughts?
---
The most important and positive thing I've gotten from this discussion is
that there's a vibrant and caring community around Sandesha. I have no
interest in trying to replicate that elsewhere and fracture this community.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
