--- Dain Sundstrom <[EMAIL PROTECTED]> 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----- > >
