buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@intalio.com>
Subject Re: is buildr still active?
Date Thu, 12 Feb 2009 01:05:37 GMT
2009/2/11 Matthieu Riou <matthieu.riou@gmail.com>

> On Wed, Feb 11, 2009 at 12:47 PM, Daniel Spiewak <djspiewak@gmail.com
> >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 <arkin@intalio.com> wrote:
> >
> > > On Wed, Feb 11, 2009 at 11:32 AM, Ittay Dror <ittayd@tikalk.com>
> 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>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message