Return-Path: Delivered-To: apmail-buildr-users-archive@www.apache.org Received: (qmail 38723 invoked from network); 11 Feb 2009 20:40:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Feb 2009 20:40:41 -0000 Received: (qmail 73995 invoked by uid 500); 11 Feb 2009 20:40:41 -0000 Delivered-To: apmail-buildr-users-archive@buildr.apache.org Received: (qmail 73971 invoked by uid 500); 11 Feb 2009 20:40:41 -0000 Mailing-List: contact users-help@buildr.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@buildr.apache.org Delivered-To: mailing list users@buildr.apache.org Received: (qmail 73960 invoked by uid 99); 11 Feb 2009 20:40:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Feb 2009 12:40:41 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of arkin@intalio.com designates 209.85.198.235 as permitted sender) Received: from [209.85.198.235] (HELO rv-out-0506.google.com) (209.85.198.235) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Feb 2009 20:40:33 +0000 Received: by rv-out-0506.google.com with SMTP id l9so84655rvb.17 for ; Wed, 11 Feb 2009 12:40:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.207.2 with SMTP id e2mr27779rvg.121.1234384809713; Wed, 11 Feb 2009 12:40:09 -0800 (PST) In-Reply-To: <499327D6.60101@tikalk.com> References: <4992AA7C.7080402@gmail.com> <3de5d7d20902110857v367113baxc44fb700a39ab02e@mail.gmail.com> <499327D6.60101@tikalk.com> Date: Wed, 11 Feb 2009 12:40:09 -0800 Message-ID: <3de5d7d20902111240q3d6367bcu38840c816bb35b9@mail.gmail.com> Subject: Re: is buildr still active? From: Assaf Arkin To: users@buildr.apache.org Content-Type: multipart/alternative; boundary=000e0cd2508819611d0462aa9cfc X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd2508819611d0462aa9cfc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 11, 2009 at 11:32 AM, Ittay Dror wrote: > > > Assaf Arkin wrote: > > Specs really really help. A patch could look simple and trivial, maybe >> it's >> a one line fix, but writing the spec and then accepting the patch is more >> work than accepting a tested patch. >> >> If you can't figure out how to fix something, but can at least write a >> spec >> to prove it's broken, that's also enormously helpful. The fix may end up >> to >> be trivial to someone else, just by running the spec and looking at the >> stack trace. >> >> So spec as much as possible. >> >> > I find the current way of submitting patches / specs to be unproductive. > It's hard for people to comment on a patch: you see an email about a patch, > need to open the issue in the browser, download the patch, read, and then > the only way to comment is writing an out-of-line comment in jira. and of > course people follow jira notices far less than the "regular" mailing lists. > Also, there are no clear coding conventions to follow. Finally, I don't > remember seeing someone's patch being accepted. I wonder how other people feel about it. I'd like to explore using Github to review patches before submitting them through JIRA. You still need to have a JIRA issue open, to track the issue, but review/commenting can be done directly on the source. Possibly even pulling changes directly from a Git repository, if you have a CLA. We have about 14,000 lines of code in lib, additional 12,000 in spec, that's a lot of convention. If you see something being used repeatedly, copy it. If you see something inconsistent, fix it. If there's no precedence, I borrow from Rails, RSpec, Rake in that order. Assaf > > > Ittay > >> Assaf >> >> >> >> >>> >>> Ittay >>> >>> >>> >>> >> >> >> > > -- > Tikal > Tikal Project > > --000e0cd2508819611d0462aa9cfc--