Jean-frederic Clere wrote:
Mladen Turk wrote:
Anyhow, what should I do, since I've volunteer for a RM?
Good questions...
I mean, I don't expect to see the 1.3 branch for couple of
months from now,
well, that's neither here nor there w.r.t. 1.2.x - whoever needs
to do new development (if 1.2 is feature-frozen) should simply branch
already. Since I believe we are ready on the svn side, this is nothing
more than an svn cp .../trunk .../branches/1.2.x
but let's leave 1.3 out of this immediate discussion
and the 1.2.14 is unusable on Solaris, so
we need some action. The 1.2.15 (bugfix) release is the
only thing that is implementable right now, thought.
Agreed, it's time to release a 1.2.15, but this is where the RM's job
is very frustrated, working independently, as opposed to working with the
dev list. I don't remember much chatter before 1.2.15 suddenly appeared,
but when most of the dev@'ers are on different pages, it can take a while
to all get back in sync.
(FWIW - 1.2.15 is going to my QA folks tonight. You probably are aware
that I had almost every free hour invested in the last few weeks getting out
new apr and httpd versions. Sorry that my focus was elsewhere.)
There are 10 open bug, what about trying to close them before the release?
That's also irrelevant - is 1.2.15 the best available version? If so, let's
release (and if you want to squish 10 bugs in a week, jf, feel free to RM
yet another release then!) The issue (not a problem, unless you are a user
who makes no contribution) is that nobody 'schedules' Apache fixes, each
contributor scratches their own itch. When everything is healthy, this means
that -someone- is likely to see a significant bug squished, or a competent
user steps up to squish it themself and offer a patch.
Since there was no reactions to the VOTE either pro or
contra for more then a mont,
seems to me we are in a serious problem,
Howso? ...
because the developers/commiter interest is blocking the release.
That's not a problem, that's a symptom. But you presume it's an unhealthy
symptom...
The final solution is either to bring that to the tomcat pmc,
and if there is really zero interest on maintaining mod_jk,
among the current commiters, it should be either shut down,
or proposed as a new project with a different set of maintainers.
Mladen, this is a bit over-the-top :) You know full well...
* you can fork and call your code base mod_jk_mt - nothing wrong with that,
it's under the Apache License. Don't call it mod_jk/Apache Tomcat Connector
and don't host it on apache.org. Don't feel put-upon if such an effort is
not warmly embraced by your fellow contributors, here.
* you can discuss 'why isn't 1.2.15 ready?' on list. Perhaps, as jfclere
observes, that some contributors have an issue with it (note no negative
vote was offered, only a reason why one contributor isn't testing it.)
Discussion is healthy.
* you can employ patience, and ping for more testers. They will likely
come along in due time. Especially Solaris testers. Recent instability
may have scared some off for the time being from testing this, now very
solid, newer code.
* finally, you can consider that, in large measure, mod_jk is 'baked', it's
been stable for years (well, 1.2.6 was), and many have little motivation
to develop/test/deploy a new flavor, if they are happy with their current
installation. This simply means that new releases will take a bit longer
to test, and a bit longer to get feedback 'from the field'.
Believe me, you aren't the first frustrated RM. But a couple-week delay
is hardly cause to sound the klaxons and drop the halon :)
As long as jk serves a purpose, suggesting that it be abandoned isn't the
right answer. Obviously jrun was ditched because it wasn't supported, but
it also was hopelessly outdated by jk. Obviously jk2 was scuttled because
it just didn't measure up to jk, it didn't serve a useful need.
But mod_jk serves a need, has maintainers/committers/reviewers. It's only
a matter of 'sheparding cats' at this point :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
