Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Janne.Jalkanen@ecyrd.com
 designates 193.64.5.122 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <A20F2232-009C-481F-AAD6-241A6A168B38@ecyrd.com>
References: <78EA94E6-5D27-479C-AAEC-694183831110@ecyrd.com>
 <1214751038.30958.253.camel@netframe>
 <2C9F19AF-C10B-4EB2-9A6E-13BD3869931F@ecyrd.com>
 <4867E6A0.4000809@altheim.com>
 <A20F2232-009C-481F-AAD6-241A6A168B38@ecyrd.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3C8AE37D-F09B-4482-A4B4-CB38ECAC9E36@ecyrd.com>
Content-Transfer-Encoding: 7bit
From: Janne Jalkanen <Janne.Jalkanen@ecyrd.com>
Subject: Re: First pass at 3.1 (also: 2.8 alphas, anyone?)
Date: Mon, 30 Jun 2008 00:41:10 +0300
To: jspwiki-dev@incubator.apache.org


And to reiterate: Can you give us a firm schedule by which time you  
*have* looked at all of the code?  Can you commit to it?

When could we start releasing new functionality?

Next week?

Next month?

In six months?

Next year?

Let's face it - if you haven't had the motivation to look at the  
modules which are unknown to you in the six months that JSPWiki 2.6  
has been out as a stable, you are not going to do it in the next six  
months either.

Please, spell out specific problems which we can start solving.  File  
them in the JIRA.  We'll deal with them.  But this is a community  
effort, and telling the community to slow down is not a good way to  
stir up their enthusiasm.

I recall we had this discussion previously, and then people were  
worried about releases coming too quickly when we bumped the build  
number as a part of the version number.  Well, we fixed it, and  
unlike with 2.4 which went up to 104 release numbers, 2.6 has only  
had four releases in the last six months.  Which I think is pretty fair.

/Janne

On 30 Jun 2008, at 00:09, Janne Jalkanen wrote:

>
> 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