On Wed, Feb 11, 2009 at 11:32 AM, Ittay Dror <[email protected]> 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 <http://www.tikalk.com> > Tikal Project <http://tikal.sourceforge.net> > >
