bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.
Changes:
*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!
Ryan Davis wrote:
bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.Changes:
*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!
Thank you! Thank you! Thank you! I'm going to go out and buy a new hard
drive and some RAM to celebrate!!
This is excellent news!
Is the Subversion repository on rubyforge going to be the main
repository for BTFS development?
Thanks,
Jeff
On 10/30/06, Ryan Davis <ryand-ruby@zenspider.com> wrote:
bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.Changes:
*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!
Ryan, is this going to be a one developer project? You have already
demonstrated your +60 "keyboard of coding might", but this still seems
like a huge project for a single individual. Are you looking for
worker bees to help out on this one?
TwP
On 10/30/06, Ryan Davis <ryand-ruby@zenspider.com> wrote:
bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.
Hi Ryan,
Who/Where should I contact with failing test information?
--
Chris
On 10/30/06, Ryan Davis <ryand-ruby@zenspider.com> wrote:
bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.Changes:
*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!
--
Chris Carter
concentrationstudios.com
brynmawrcs.com
Ryan Davis wrote:
bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.
Ryan,
Feel free to grab whatever you want from ruby_test (in SCM as part of
the 'shards' project):
http://rubyforge.org/projects/shards/
Regards,
Dan
Thanks! I just bought a new mac mini to replace an old loud freebsd server with a dying hard drive so make sure the RAM works with a mini and the hard drive is firewire.
Thanks Again!
Ryan
On Oct 30, 2006, at 5:25 PM, M. Edward (Ed) Borasky wrote:
Thank you! Thank you! Thank you! I'm going to go out and buy a new hard
drive and some RAM to celebrate!!
This is excellent news!
thanks
Is the Subversion repository on rubyforge going to be the main
repository for BTFS development?
Actually no, it is just a mirror of the real repo. I got tired of people pretending that perforce was too high a hurdle to deal with so I started mirroring it to svn using svk. I think today I'm going to write something to replace svk because it is some of the worst and buggiest perl I've dealt with in a long time and all I need is a simple 1-way mirror.
On Oct 31, 2006, at 5:11 AM, Jeff Dik wrote:
bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.Ryan, is this going to be a one developer project?
Oh hell no.
You have already
demonstrated your +60 "keyboard of coding might", but this still seems
like a huge project for a single individual. Are you looking for
worker bees to help out on this one?
PLEASE. +60 VORPAL keyboard of coding might!
Yes, we'd love other contributors.
On Oct 31, 2006, at 11:55 AM, Tim Pease wrote:
On 10/30/06, Ryan Davis <ryand-ruby@zenspider.com> wrote:
http://rubyforge.org/projects/bfts
file a bug pls. that way we can track em.
On Nov 1, 2006, at 7:02 AM, Chris Carter wrote:
Who/Where should I contact with failing test information?
If I do, and you are happy with the merger, will you delete yours?
Yes, I'm trying for some unification here.
On Nov 1, 2006, at 9:15 AM, Daniel Berger wrote:
Feel free to grab whatever you want from ruby_test (in SCM as part of
the 'shards' project):
Myself being one of those people who are stubborn about using
Perforce, I am glad to hear about a mirror. One tool that I have found
really useful is tailor [1]. It doesn't support Perforce yet but you
might want to look at it if you aren't afraid of Python code.
Though, I would still encourage you to consider a distributed SCM
system (and no -- I don't like svk at all). I get a lot of my free
project time while traveling. I am offline long enough during those
periods that a system that it pays off tremendously. I don't want to
argue other possible differences as it is just a matter of style (to a
point).
Thanks,
Brian.
[1] Darcs - RelatedSoftware/Tailor
On 10/31/06, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Oct 31, 2006, at 5:11 AM, Jeff Dik wrote:
> This is excellent news!
thanks
> Is the Subversion repository on rubyforge going to be the main
> repository for BTFS development?Actually no, it is just a mirror of the real repo. I got tired of
people pretending that perforce was too high a hurdle to deal with so
I started mirroring it to svn using svk. I think today I'm going to
write something to replace svk because it is some of the worst and
buggiest perl I've dealt with in a long time and all I need is a
simple 1-way mirror.
I don't think it's too high a hurdle, it's just an unnecessary one. I'm
sure you've got good reasons for preferring it to svn, but I don't know
what they are.
I'd be interested to hear why you prefer your own p4 repo to using
RubyForge's svn.
Ben
On Wed, Nov 01, 2006, Ryan Davis wrote:
Actually no, it is just a mirror of the real repo. I got tired of
people pretending that perforce was too high a hurdle to deal with so
I started mirroring it to svn using svk. I think today I'm going to
write something to replace svk because it is some of the worst and
buggiest perl I've dealt with in a long time and all I need is a
simple 1-way mirror.
Ryan Davis wrote:
You have already
demonstrated your +60 "keyboard of coding might", but this still seems
like a huge project for a single individual. Are you looking for
worker bees to help out on this one?PLEASE. +60 VORPAL keyboard of coding might!
Yes, we'd love other contributors.
I understand SCM preference, but this is probably the primary reason projects choose SVN or CVS over anything else. Your average contributor is going to be far more likely to know SVN or CVS than P4 or anything else. Also, direct tool support for those tends to be greater because they're 100% free and pervasive in the OSS community.
So the tradeoff for your SCM of preference (P4) is ease of contribution. If that's not as important, no problem. It would never work for JRuby, for example, where we have something like 20 external contributors throwing patches at us and even more running off trunk.
On Oct 31, 2006, at 11:55 AM, Tim Pease wrote:
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
Ryan Davis wrote:
> Feel free to grab whatever you want from ruby_test (in SCM as part of
> the 'shards' project):
>
> http://rubyforge.org/projects/shards/If I do, and you are happy with the merger, will you delete yours?
Sorry for the late reply...
I'm afraid I'm unwilling to budge on the "one method, one file"
organization for the tests, at least for core Ruby. I'm also not sure
what your feelings are regarding benchmarks, which I use as a form of
high iteration testing as well as a way to check for pathological
slowdowns.
I think you'll find that sticking all class and instance methods for a
given class in one file will become unmanageable over time, especially
when you consider platform specific tests, $SAFE tests, etc. IMHO,
separating the methods makes the tests easier to manage and will make
it easier for other people to contribute test cases.
Regards,
Dan
On Nov 1, 2006, at 9:15 AM, Daniel Berger wrote:
Myself being one of those people who are stubborn about using
Perforce, I am glad to hear about a mirror. One tool that I have found
really useful is tailor [1]. It doesn't support Perforce yet but you
might want to look at it if you aren't afraid of Python code.
*nod* I'll poke at this. I suspect I need less than 30 lines of ruby or shell to do this tho.
Though, I would still encourage you to consider a distributed SCM
system (and no -- I don't like svk at all). I get a lot of my free
project time while traveling. I am offline long enough during those
periods that a system that it pays off tremendously. I don't want to
argue other possible differences as it is just a matter of style (to a
point).
ain't gonna happen.
On Oct 31, 2006, at 11:00 AM, Brian Mitchell wrote:
I don't think it's too high a hurdle, it's just an unnecessary one. I'm
sure you've got good reasons for preferring it to svn, but I don't know
what they are.
how about: subversion blows multicolored chunks?
I'd be interested to hear why you prefer your own p4 repo to using
RubyForge's svn.
see above.
On Oct 31, 2006, at 11:01 AM, Ben Bleything wrote:
Charles Oliver Nutter wrote:
Ryan Davis wrote:
You have already
demonstrated your +60 "keyboard of coding might", but this still seems
like a huge project for a single individual. Are you looking for
worker bees to help out on this one?PLEASE. +60 VORPAL keyboard of coding might!
Yes, we'd love other contributors.
I understand SCM preference, but this is probably the primary reason
projects choose SVN or CVS over anything else. Your average contributor
is going to be far more likely to know SVN or CVS than P4 or anything
else. Also, direct tool support for those tends to be greater because
they're 100% free and pervasive in the OSS community.So the tradeoff for your SCM of preference (P4) is ease of contribution.
If that's not as important, no problem. It would never work for JRuby,
for example, where we have something like 20 external contributors
throwing patches at us and even more running off trunk.
I'd be happy if the CVS and SVN folks would settle their war so I don't
need to learn both. 
Seriously, though, I have two projects on RubyForge, one in CVS and the
other in SVN. Don't ask me why; I don't know. The only one I use
actively is the CVS one.
On Oct 31, 2006, at 11:55 AM, Tim Pease wrote:
plz elaborate? It works fine for me and lots of other folks. Again,
I'm not arguing with your opinion, I'm just curious. We used p4 at an
old job of mine and everyone loved it. It's just not as easily
accessable as svn.
Ben
On Wed, Nov 01, 2006, Ryan Davis wrote:
how about: subversion blows multicolored chunks?
Sure, ruby-talk generates a lot of traffic, but I stay subscribed to enjoy the scintillating repartee...
Tom
On Oct 31, 2006, at 2:08 PM, Ryan Davis wrote:
On Oct 31, 2006, at 11:01 AM, Ben Bleything wrote:
I don't think it's too high a hurdle, it's just an unnecessary one. I'm
sure you've got good reasons for preferring it to svn, but I don't know
what they are.how about: subversion blows multicolored chunks?
I'd be interested to hear why you prefer your own p4 repo to using
RubyForge's svn.see above.