[rspec-devel] Back to one repository?

Matthijs Langenberg mlangenberg at gmail.com
Fri May 2 16:27:06 EDT 2008


+1 Dan, a CI with nightly gem builds would be great.
Still, what to do with 'Type 3: rspec hacker'? How should that repository
look?

- Matt


On Fri, May 2, 2008 at 10:00 PM, Dan North <tastapod at gmail.com> wrote:

> Hi folks. Are we trying to solve the wrong problem?
>
> Type 1: vanilla rspec user
>
> - gem install rspec --source http://rspec.info/rspec-edge.gem
>
> Type 2: rails rspec user
>
> - gem install rspec --source http://rspec.info/rspec-edge.gem
>
> Type 3: rspec hacker
>
> - git clone
>
> Type 4: textmate bundle user
>
> - however textmate bundles are usually packaged up, as a wget
>
>
> I'm coming from the java world where I guess I use around a dozen open
> source libraries on a regular basis. I almost never check out the sources
> from scm - I just download the jars (occasionally with source zips). For
> bleeding-edge versions of java projects they often provide nightly builds.
> The java world is just catching up with gem-style dependency management, but
> even without that it's easy to keep up with
>
> gem install takes a source url, so providing edge gems should be as easy
> as having an automated build on every commit that builds and publishes the
> gems. We can also bundle the examples, docs & internal specs with the gem
> for reference and inspiration. (The ramaze gem is a really nice example of
> this.)
>
> The use cases should determine the end artifacts of a build process,
> rather than the way we should be structuring the source repo. The source
> repo should be structured to make it easiest to navigate and find code.
>
> I'd love to be able to step up and offer to put a CI build in place, but I
> don't have the bandwidth at the moment. I'm happy to work with anyone who
> wants to take it up though.
>
> Cheers,
> Dan
>
>
> 2008/5/1 Ian Dees <undees at gmail.com>:
>
> Hi, all.
> >
> > Quoth David:
> >
> > >  We also need to consider the Ruby developer who doesn't use rails.
> > We'd be forcing that user to clone a bunch of stuff they don't need. I'm not
> > sure how important an issue that is when weighed against everything else,
> > but it is certainly a consideration.
> >
> > I can at least offer one data point on this note.  Most of my RSpec
> > work is non-Rails, and I don't mind having the Rails stuff in there.
> > The amount of extra disk space and clone time it adds doesn't even
> > show up on the radar.
> >
> > If a new layout required me to drill down into example_rails_app to
> > get at the code, that wouldn't be the end of the world, especially if
> > we had a symlink at the top level or an explanation in the README.
> > The extra conceptual effort is about the same as running rake
> > git:update.
> >
> > --Ian
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080502/0b34c7bb/attachment-0001.html>


More information about the rspec-devel mailing list