From dev-return-95841-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Jul 25 17:02:35 2007 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 80249 invoked from network); 25 Jul 2007 17:02:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Jul 2007 17:02:26 -0000 Received: (qmail 94365 invoked by uid 500); 25 Jul 2007 17:02:21 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 94308 invoked by uid 500); 25 Jul 2007 17:02:21 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 94272 invoked by uid 99); 25 Jul 2007 17:02:21 -0000 X-ASF-Spam-Status: No, hits=-98.4 required=10.0 tests=ALL_TRUSTED,GAPPY_SUBJECT X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO carsten-ziegelers-computer.local) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jul 2007 10:02:21 -0700 Message-ID: <46A7828D.3000203@apache.org> Date: Wed, 25 Jul 2007 19:04:13 +0200 From: Carsten Ziegeler User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: HttpServletRequest vs o.a.c.e.Request saga continues References: <46A77D9A.4000102@tuffmail.com> In-Reply-To: <46A77D9A.4000102@tuffmail.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Grzegorz Kossakowski wrote: > Hi guys, > > > > This lists could be much longer. This lists make me sick because it was > never as much painful to develop something Cocoon-related as this GSoC > work. I was prepared to some obstacles, world is not perfect, I knew > that our internals are far from perfection. Now I know that they are > fucking crazy, period. > :) Ok, all this is definitly not optimal and it now pays back that we never paid enough attention when the various parts were developed by different people. I understand your frustration and I would opt for clearing everything up in your situation as well. I personally have no problems with breaking the contracts for 2.2 in some places if it makes sense. We changed already a lot of things, so why not changing some more? The question is do we loose users just because of this? I don't think so. BUT, there is still no final release of 2.2 and it's not even visible when this will happen. Such changes will create the nice and easy argument to delay the release further. I still would prefer to release 2.2 *today* (well today is not feasible, but let's say in the next 7 days) and directly afterwards do this refactoring. Not changing the environment abstraction is a mistake, but not releasing is imho a much bigger one. Carsten -- Carsten Ziegeler cziegeler@apache.org