Back when the issue of picking a chair first came up, I said I would
take a turn if needed. Of course, I've since dropped out and am no
longer eligible. My main reason for dropping out was that I felt there
was insufficient user community input and support for a viable project.
In particular, I was concerned about attempting performance improvement
with no user workload derived benchmarks.
I have been following the various discussions on the dev mailing list,
including this one. If you would like me to return and run for chair,
please reinstate me as a committer and PMC member.
My main agenda would be to find out if there is a sufficient user
community to make River viable. Without community input, there is no
rational basis for making decisions, and little point to the whole
exercise. With an active user community, there would be a path forward.
If any of the active PMC members is even insufficiently reluctant to
take on being chair, I'll immediately withdraw my candidacy.
I think I may still get the private mailing list. If you wish to discuss
me behind my back, please include "NOT PATRICIA" in the subject, and
I'll delete the message without reading it.
Patricia
On 5/13/2014 6:16 AM, Greg Trasuk wrote:
So who wants to stand for election as the new chair?
Cheers,
Greg Trasuk.
On May 13, 2014, at 8:46 AM, Bryan Thompson <br...@systap.com> wrote:
Sounds good.
On May 13, 2014, at 8:25 AM, Rafał Krupiński <rafal.krupin...@sorcersoft.com>
wrote:
Dnia wtorek, 13 maja 2014 08:11:21 Bryan Thompson pisze:
Is the name change a requirement for a 3.0? The problem is that this will
break compatibility making it extremely difficult to establish performance
in existing applications while preserving the ability to rollback to a
known good code base. I would have to give a -1 to this. We need to
validate the release against running systems before changing the
namespaces. If that means keeping this a 2.x release, that's fine.
Change namespaces can be made in a compatible way. There could be additional
jars with empty classes in the old packages that would just extend the classes
in the new packages, like below:
//some-module.jar
org.apache.river.SimeClass{
//class moved from net.jini
}
//some-module-compat.jar (that depends on some-module.jar)
net.jini.SomeClass extends org.apache.river.SomeClass{
//empty class
}
In order to migrate to the new version, you'd need to replace the actual
module and add the compatibility module.
Regards
Rafał
