I'm sorry - I completely and utterly disagree with your assessment of
the situation.
The point of JSPWiki 2.8 was to release an Apache-licensed version of
JSPWiki 2.6. We need to do this in order to be a part of Apache,
which we agreed that was a good idea.
Are you now saying that we should not do this because you guys can't
keep up with the license changes?
Or are you saying that the events or plugins or AAA or workflow or
page management are not working at the moment? If there are any
issues, why are they not filed in the JIRA?
You know, *I* don't know the workflow or the AAA code, and I think I
spend the most of the time banging at this thing. But I don't
*care*, because I trust Andrew to do a good job on it, and most of
the time, I don't *need* it. If we have to wait consensus that every
single person in the dev team understands every single bit of code
that's in the codebase - we can just forget about the whole thing and
go home. There is just too much of it.
I don't understand why you need to understand all of the code? So
what if there are features which you don't need? If they are
interfering with you, you should propose mechanisms with which we can
cope with the complexity - but slowing things down ain't it.
I recently saw a wonderful presentation about the Linux kernel.
Here's some statistics:
<snip>
Turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did:
lines added per day: 4945
lines removed per day: 2006
lines modified per day: 1702
And note, that is real stuff, not renames or file moves at all, git
handles not reporting that.
</snip>
*per day* And the speed is increasing. Without any formal
acceptance testing, even.
Yet it all works really well. Why? Because people trust other
people, who are working on the code, even though they don't know what
exactly it is that they are doing.
Please, I would like to see some constructive proposals as to what
could be done to remedy the issues you are having as opposed to a
generic "slow down please". I don't for a single instant believe
that it would solve anything - it could possibly alienate users,
since the competition is out there, and it *is* getting better. As
with all large projects, one must learn how to drink from the
firehose. If you need to continuously patch certain things, then
perhaps you would like to propose a mechanism to modularize those?
Or at least file a JIRA wish? Or perhaps start driving a binary
compatibility program? Or even start a page enumerating the things
which you don't understand as opposed to just generically complaining
about some unknown branches?
We need to be way more specific as to what the issues are rather than
to "slow down". We need to know exactly what breaks, what works, and
what can we do to increase our rate of change in a way which does not
bother people who only occasionally peek into the codebase. Because
as JSPWiki grows larger and better and attracts more developers (as
an Apache project probably will) - the rate of change *will* increase.
I see your concern. I just think that you've not spent nearly enough
time analyzing it, and are mistaken in your proposal as to what would
help fixing it.
/Janne
On 29 Jun 2008, at 22:46, Murray Altheim wrote:
Janne,
I think Terry's point should probably be taken fairly to heart. While
it's great that the project can move forward quickly, even your most
devoted developers (myself included) don't generally sound like
they're
keeping up with the rate of change -- I certainly am not -- witnessed
by the fact that almost nobody has even *looked* at some of the new
features, e.g., work flows. I would also like to have JSPWiki settle
into a period of consolidation to get basically all the foundation
code (events, plugins, AAA, workflow, page management, etc.)
solidified
before we jump forward into the next stage.
I look at the cvs directory and it's got a LOT of sub-project and
branch directories that I know nothing about. I hope I'm unusual in
that regard.
I'm probably chomping at the bit as much as anyone for some of the new
features (priha in particular) but by the same token I can't keep up
either with all the releases. I know that when some of those features
come to fruition I'm going to have an enormous amount of work in
refactoring all my own code to be compatible with the new stuff, so
you'll probably see me go to ground even more than recently, simply
trying to keep up. A change to JSPWiki's code can have profound
consequences for those of us who've built systems or sites around it.
And yes, some of us *could* be using older releases but in my case
at least I generally am using as recent a release as is stable given
the bug fixes and compatibility with my own code.
A hopefully gentle request to slow down a bit.... :-)
Murray
Janne Jalkanen wrote:
The goal of 2.8 was to create an Apache-licensed version of 2.6,
which is necessary for the incubation process.
So there really isn't that much functional difference between 2.6
and 2.8. Lots of bugfixes mainly, and some changes in the auth
stuff, and some enhancements in the UI (like section editing).
If 2.6 is working for you, then great! There is *no* need to
upgrade to the latest version (I personally still run Tomcat 5.5
in quite a few places). However, our support for 2.6 (= Janne's
interest to make bug fixes for 2.6) will be pretty much terminated
after 2.8 goes stable (barring some major security issues) - but
if there is a person who wants to start maintaining 2.6, it'd be
great!
Besides, 2.6 was released over six months ago. I think a major
release twice a year is not very fast.
Personally, I think that the fact that we can bring in new
developers, and have those people contribute to the code base in a
rapid cycle is very valuable.
/Janne
On 29 Jun 2008, at 17:50, Terry Steichen wrote:
Yeah, well I'm still scrubbing 2.6.2. You're making my head
spin. I
think we're churning out new code and new features much faster than
users can really assimilate it. I'd like things to settle down more
between versions if we want production-quality code that's not
largely
obsolete (and unsupported) by the time it's deployed.
Just my $0.02
On Sun, 2008-06-29 at 14:43 +0300, Janne Jalkanen wrote:
BTW, I think that 2.8 is ripe for an alpha release. Any objections
if we start the alpha/beta cycle for 2.8 now? That way we would
have
something for people to test and mature.
/Janne
--
......................................................................
.....
Murray Altheim <murray07 at altheim.com>
=== = =
http://www.altheim.com/murray/
= = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk
= = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
