Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 98949 invoked from network); 16 Jun 2006 21:36:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Jun 2006 21:36:07 -0000 Received: (qmail 65840 invoked by uid 500); 16 Jun 2006 21:36:03 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 65798 invoked by uid 500); 16 Jun 2006 21:36:02 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 65777 invoked by uid 99); 16 Jun 2006 21:36:02 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Jun 2006 14:36:02 -0700 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,RCVD_IN_SORBS_WEB X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [206.190.49.136] (HELO web54406.mail.yahoo.com) (206.190.49.136) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 16 Jun 2006 14:36:01 -0700 Received: (qmail 84746 invoked by uid 60001); 16 Jun 2006 21:35:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SzK+9nhrDsDkdUlPzK3xaMhaeefFIib2/SFKhXHJ6WV5X6lz4bDv13MfRe68r1gObnLBux5UJCiQE0sUNk7qo+VOCSUWNFKmxAGGDVKDIeziOtVVcmhV6NrMH6uL0C90r7bBjruEmmwkBi+Ce57AwYa5qv2Tte/4/HTL8BEHC6I= ; Message-ID: <20060616213536.84744.qmail@web54406.mail.yahoo.com> Received: from [208.54.95.129] by web54406.mail.yahoo.com via HTTP; Fri, 16 Jun 2006 14:35:36 PDT Date: Fri, 16 Jun 2006 14:35:36 -0700 (PDT) From: David Jencks Subject: Re: [RTC] ?? Review requested on intermediate patches for pluggable JACC To: dev@geronimo.apache.org In-Reply-To: <2CDA46D2-31AE-44AD-9714-23BCD62D1127@iq80.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --- Dain Sundstrom wrote: > I have two thoughts: > > 1) we have an automated tool to track patches and it > can track votes > and send out these reports. > I'm not convinced automating this will work all that well. I do think that all +1 and suggestions should be made as comments on the jira issue. I think it can be up to the proposer to kick people on the dev list if it's getting ignored. If someone can really figure out how to do +1's in jira automatically, fine.... i'm not a jira expert and don't know how much this would conflict with the current meaning of voting. > 2) IMHO, if patchs start taking longer than a few > days to get > committed, we as a project are not going to be > successful. I like > the discussions that RTC raise, but we also need to > progress > quickly. Over think will kill this project as fast > as no-thinking. I completely agree. We're still startng to learn how to do RTC, but I think its already clear that without fairly quick review turnaround there's a danger that people will lose interest. thanks david jencks > > -dain > > On Jun 16, 2006, at 3:35 AM, Rodent of Unusual Size > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > One thing that a number of the projects do is > maintain a > > STATUS file with open issues, and have it send to > the > > dev list once a week. > > > > This has been particularly useful for tracking the > status > > of patches during RTC. When someone puts up a > patch for > > review, it gets added to the STATUS file with a > brief > > description and a pointer to where the patch can > be > > obtained. As people review it, they add their > +1/-1 > > votes to the item. > > > > This allows the whole project to see at any time > what > > patches are up for review, keeps the issues and > opinions > > together and unforgotten so the status doesn't > need to > > be culled from the mailing list, and so on. > > > > It's also useful for CTR environments, although > it's > > easier to forget to keep it maintained. In RTC it > > tends to serve as *the* authoritative reference > for > > what's going on; if it isn't in the STATUS file, > it > > isn't happening. :-) > > > > Here's an example: > > > http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS > > > > We *have* a STATUS file, which was last used > during > > incubation. I propose we reactivate it for this > purpise, > > and I can add it to the job that already sends > these out > > for over a dozen other projects. > > > > Thoughts? > > - -- > > #ken P-)} > > > > Ken Coar, Sanagendamgagwedweinini > http://Ken.Coar.Org/ > > Author, developer, opinionist > http://Apache-Server.Com/ > > > > "Millennium hand and shrimp!" > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.4 (MingW32) > > Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org > > > > > iQCVAwUBRJKJgJrNPMCpn3XdAQLd3gQAj+ikphV6+2lOj533QjbSqJ9xdm/5T/Lm > > > uFBhEhxSpOpv+CVss9Mh0WAC+Btlfby3ZRsvuY2ptyq8Wb1ZuMHR8QdxFZ2jua+A > > > 8C+8irJZtptG0oga2IYPn2iE5ikDjJ7Z5FvQtL3qc5xwrByFOvvi6EzHWII8w6ue > > kCnYBsGI3Lk= > > =bJXp > > -----END PGP SIGNATURE----- > >