2009/2/11 Matthieu Riou <[email protected]> > On Wed, Feb 11, 2009 at 12:47 PM, Daniel Spiewak <[email protected] > >wrote: > > > GitHub is definitely the easiest way to contribute code. Though, I > haven't > > had any contributions accepted yet, so who am I to say? (hint, hint) > ;-) > > > > Alternatively, using Git to develop a patch and then JIRA to submit isn't > > too bad either. Once you get over the initial learning curve (which > isn't > > too severe), Buildr is a remarkably easy project to contribute to. The > > architecture is reasonably consistent, and the code is pretty > > self-documenting. The best technique seems to be just to dive in and try > > to > > do stuff. For example, try to add a test framework provider, modify a > > compiler, or add support for some other tool (e.g. ANTLR anyone?). > > > I've contributed this back in the days: > > > http://github.com/assaf/buildr/blob/23ead9b569b373e659788fdaef2fdfb95029095b/addon/buildr/antlr.rb > > Still works for me (tm). Assaf will probably grumble that there are no > specs > for it, therefore it doesn't exist ;) But i find it useful for something > that doesn't exist.
/addon is the land to which we banish all code that doesn't have specs, or a good excuse for not having them :-) Assaf > > > Matthieu > > > > All of > > this can be a very educational experience. I won't pretend to know the > > whole project yet, but I'm well on my way. > > > > Daniel > > > > On Wed, Feb 11, 2009 at 2:40 PM, Assaf Arkin <[email protected]> wrote: > > > > > 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> > > > > > > > > > > > > > >
