[ANN] bfts 1.0.0 Released

Discussion in 'Ruby' started by Ryan Davis, Oct 31, 2006.

  1. Ryan Davis

    Ryan Davis Guest

    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!

    http://rubyforge.org/projects/bfts
     
    Ryan Davis, Oct 31, 2006
    #1
    1. Advertising

  2. 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!
    >
    > http://rubyforge.org/projects/bfts
    >
    >
    >

    Thank you! Thank you! Thank you! I'm going to go out and buy a new hard
    drive and some RAM to celebrate!!
     
    M. Edward (Ed) Borasky, Oct 31, 2006
    #2
    1. Advertising

  3. On Wed, Nov 01, 2006, Ryan Davis wrote:
    > Try to figure out how to emulate 'p4 describe' and make it just as
    > fast as perforce. For that matter, 'p4 filelog', 'p4 changes', and
    > 'p4 opened -a' (haha, you can't do that one!)


    granted

    > Oh! And try diffing while ignoring whitespace! HAHAHAHA Real friendly
    > there!


    also granted

    > o rly? What backend does rails use?


    No idea. If it's at rubyforge, fsfs apparently.

    > Yup. HUGE hurdle there... and I thought working with the brilliance
    > that is my code would be worth that. :p I suppose I could create a
    > script to automate this, but it is a one time shot so I don't see it
    > being worth that. I guess I should consider it a bozo filter. Those
    > people that seriously want to work on our projects will jump through
    > our hoops. Those that don't, won't.


    Not a hurdle. You just asked why it's harder to adopt... 8 steps vs. 2
    steps... even if those 8 steps are easy (which they are!). Speaking of
    which, look for an email from me soon to get set up :p

    > That is a feature and a damned good one I wish svn had. "Oh? Eric is
    > working on this file? Maybe I should talk to him before I go ripping
    > stuff up!" Communication. What software development is REALLY about...


    Yup, again, personal preference. I don't miss it because I've never
    needed it. Ask me again once I have and I'm sure I'll be on your side.

    > >Again, not bad, just different... but in a way that does make it a
    > >pain to adopt.

    >
    > bah


    I agree.

    Ben
     
    Ben Bleything, Oct 31, 2006
    #3
  4. Ryan Davis

    Ryan Davis Guest

    On Oct 31, 2006, at 11:55 AM, Tim Pease wrote:

    > On 10/30/06, 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, 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.
     
    Ryan Davis, Oct 31, 2006
    #4
  5. Ryan Davis

    Bill Kelly Guest

    From: "Ryan Davis" <>
    >
    > On Oct 31, 2006, at 11:46 AM, Ben Bleything wrote:
    >
    >> There's also the whole "lock individual files with 'p4 edit'" thing,
    >> which I admit is purely personal preference, but I like the svn
    >> workflow
    >> better.

    >
    > That is a feature and a damned good one I wish svn had. "Oh? Eric is
    > working on this file? Maybe I should talk to him before I go ripping
    > stuff up!" Communication. What software development is REALLY about...


    Interesting. The kind of Communication I remember as the
    staple of locking-style VC projects went something like this:
    "Bob, I need access to frobozz.cpp, will you be checking in
    soon?" "Well, I haven't changed frobozz very much, but if I
    check it in it won't compile for you. I can't check it in until
    I finish with XYZZY, then I'll check in all these files at once."
    "Oh... well I guess I'll just modify my copy locally and merge
    manually, as usual."

    I *never* want to go back to that. Maybe this isn't so much
    of an issue with p4, since it apparently _does_ know how to
    merge changes? (The old locking-style VC systems I used didn't
    know about merging at all.)

    Just wondering,

    Bill
     
    Bill Kelly, Oct 31, 2006
    #5
  6. Ryan Davis wrote:
    >
    > On Oct 31, 2006, at 11:55 AM, Tim Pease 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.

    --
    Charles Oliver Nutter, JRuby Core Developer
    Blogging on Ruby and Java @ headius.blogspot.com
    Help spec out Ruby today! @ www.headius.com/rubyspec
    --
     
    Charles Oliver Nutter, Oct 31, 2006
    #6
  7. Charles Oliver Nutter wrote:
    > Ryan Davis wrote:
    >>
    >> On Oct 31, 2006, at 11:55 AM, Tim Pease 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.
     
    M. Edward (Ed) Borasky, Nov 1, 2006
    #7
  8. M. Edward (Ed) Borasky wrote:
    > 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.


    I can't say I'm a huge fan of either, but they're no-brainers to use for
    open source. Not with any other SCM could I just toss an offhand URL out
    and know that people would be able to handle everything. Really all I
    need to do to get someone involved is say "it's in SVN, here's the URL".
    Done and done. That's a huge advantage for getting folks involved.

    And as slow as it is, the DAV-based SVN servers are just about the
    easiest ones to work with. Not only you can use non-SVN tools to pull
    files if necessary (i.e. mount as a folder if you wish) but you can poke
    around in an ordinary web browser. Unpleasant for day-to-day commits,
    but trivial to make source available to a wide audience.

    --
    Charles Oliver Nutter, JRuby Core Developer
    Blogging on Ruby and Java @ headius.blogspot.com
    Help spec out Ruby today! @ www.headius.com/rubyspec
    --
     
    Charles Oliver Nutter, Nov 1, 2006
    #8
  9. On 10/31/06, Bill Kelly <> wrote:
    > Interesting. The kind of Communication I remember as the
    > staple of locking-style VC projects went something like this:
    > "Bob, I need access to frobozz.cpp, will you be checking in
    > soon?" "Well, I haven't changed frobozz very much, but if I
    > check it in it won't compile for you. I can't check it in until
    > I finish with XYZZY, then I'll check in all these files at once."
    > "Oh... well I guess I'll just modify my copy locally and merge
    > manually, as usual."
    >
    > I *never* want to go back to that. Maybe this isn't so much
    > of an issue with p4, since it apparently _does_ know how to
    > merge changes? (The old locking-style VC systems I used didn't
    > know about merging at all.)


    It isn't an issue with p4. We use it at work. Even if Perforce didn't
    offer free licenses for open source work, it's worth every freakin'
    penny.

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Nov 1, 2006
    #9
  10. [OT] Re: [ANN] bfts 1.0.0 Released

    ok, since this thread has veered it's head toward SCMs, I'm also
    throwing in my irrelevant opinion. Git has been a most welcome
    addition to my workflow: distributed, direct, easy branching and (so
    far) good merging. Oh, and it has git-cvsserver that serves as a
    two-way bridge for those that insist on CVS (albeit for a simple
    subset of CVS commands).

    It can be served read-only from an http mounted directory (although
    not efficiently), and comes with a perl CGI script to view repos.

    Cameron

    p.s. I agree with the multicolored chunks bit.
     
    Cameron McBride, Nov 1, 2006
    #10
  11. Re: bfts 1.0.0 Released

    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
     
    Daniel Berger, Nov 1, 2006
    #11
  12. Ryan Davis

    Ryan Davis Guest

    On Nov 1, 2006, at 7:02 AM, Chris Carter wrote:

    > Who/Where should I contact with failing test information?


    http://rubyforge.org/projects/bfts

    file a bug pls. that way we can track em.
     
    Ryan Davis, Nov 1, 2006
    #12
  13. Ryan Davis

    Ryan Davis Guest

    Re: bfts 1.0.0 Released

    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):
    >
    > http://rubyforge.org/projects/shards/


    If I do, and you are happy with the merger, will you delete yours?

    Yes, I'm trying for some unification here.
     
    Ryan Davis, Nov 1, 2006
    #13
  14. Re: bfts 1.0.0 Released

    Ryan Davis wrote:
    > 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):
    > >
    > > 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
     
    Daniel Berger, Nov 14, 2006
    #14
  15. On Wed, Nov 01, 2006, Ryan Davis wrote:
    > >- The 7ish steps listed at http://zenspider.com/ZSS/Process/
    > >Perforce.html,
    > > including one where I wait for you to set up my user

    >
    > Yup. HUGE hurdle there... and I thought working with the brilliance
    > that is my code would be worth that. :p I suppose I could create a
    > script to automate this, but it is a one time shot so I don't see it
    > being worth that. I guess I should consider it a bozo filter. Those
    > people that seriously want to work on our projects will jump through
    > our hoops. Those that don't, won't.


    As it turns out, this apparently is a hurdle. The day this thread was
    new I sent you an email asking you to set me up. Haven't heard back
    yet.

    The email probably got lost, which obviously isn't anyone's fault, but
    if it were in svn on RubyForge (for instance) we wouldn't have this
    problem.

    Ben
     
    Ben Bleything, Nov 16, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom Hawkins

    [ANN] Confluence 0.7.1 Released

    Tom Hawkins, Oct 23, 2003, in forum: VHDL
    Replies:
    0
    Views:
    495
    Tom Hawkins
    Oct 23, 2003
  2. Tom Hawkins

    [ANN] InFormal 0.1.1 Released

    Tom Hawkins, Nov 9, 2004, in forum: VHDL
    Replies:
    2
    Views:
    486
    Tom Hawkins
    Nov 9, 2004
  3. Jussi Jumppanen

    ANN: Zeus Version 3.95 Editor Released

    Jussi Jumppanen, Aug 8, 2005, in forum: VHDL
    Replies:
    0
    Views:
    434
    Jussi Jumppanen
    Aug 8, 2005
  4. Al Ponomarev
    Replies:
    3
    Views:
    463
    Ken Cox [Microsoft MVP]
    May 3, 2004
  5. Chris Roos
    Replies:
    25
    Views:
    252
    Isaac Gouy
    Sep 17, 2006
Loading...

Share This Page