[Project Idea] RCM - A Ruby Configuration Management System

Discussion in 'Ruby' started by Michael Neumann, Jun 27, 2005.

  1. Hi all,

    Is there anyone interested in joining a project that aims at creating a
    Monotone (www.venge.net/monotone) inspired distributed configuration
    management system in Ruby?

    Major goal is clean and understandable code, good abstractions and high code
    quality, from which further ideas could be implemented more easily than is
    the case for Monotone (at least for me).

    Ultimate goal of course is the switch from CVS to RCM for the development of
    the ruby interpreter ;-)

    Or do we want to let Python win the race? ;-)

    Regards,

    Michael
    Michael Neumann, Jun 27, 2005
    #1
    1. Advertising

  2. Michael Neumann ha scritto:
    > Hi all,
    >
    > Is there anyone interested in joining a project that aims at creating a
    > Monotone (www.venge.net/monotone) inspired distributed configuration
    > management system in Ruby?
    >
    > Major goal is clean and understandable code, good abstractions and high code
    > quality, from which further ideas could be implemented more easily than is
    > the case for Monotone (at least for me).
    >
    > Ultimate goal of course is the switch from CVS to RCM for the development of
    > the ruby interpreter ;-)
    >
    > Or do we want to let Python win the race? ;-)


    have you considered joining forces with Zed Shaw's FastCST?
    I don't know what features you're planning to take out from monotone,
    but since FCST is based on the idea of plugins to add functionalities, I
    imagine you could possibly add them..
    gabriele renzi, Jun 27, 2005
    #2
    1. Advertising

  3. Am Monday 27 June 2005 18:35 schrieb gabriele renzi:
    > Michael Neumann ha scritto:
    > > Hi all,
    > >
    > > Is there anyone interested in joining a project that aims at creating a
    > > Monotone (www.venge.net/monotone) inspired distributed configuration
    > > management system in Ruby?
    > >
    > > Major goal is clean and understandable code, good abstractions and high
    > > code quality, from which further ideas could be implemented more easily
    > > than is the case for Monotone (at least for me).
    > >
    > > Ultimate goal of course is the switch from CVS to RCM for the development
    > > of the ruby interpreter ;-)
    > >
    > > Or do we want to let Python win the race? ;-)

    >
    > have you considered joining forces with Zed Shaw's FastCST?


    Yes, I wrote him an email just before writing this.

    > I don't know what features you're planning to take out from monotone,
    > but since FCST is based on the idea of plugins to add functionalities, I
    > imagine you could possibly add them..


    Mainly how Monotone works internally. But the plugin idea is definitly an
    interesting idea...

    Main problem is that it has to be accepted and used by a couple of people.
    Using a CM system alone is no fun.

    Regards,

    Michael
    Michael Neumann, Jun 27, 2005
    #3
  4. Michael Neumann wrote:

    > Is there anyone interested in joining a project that aims at creating a
    > Monotone (www.venge.net/monotone) inspired distributed configuration
    > management system in Ruby?


    I don’t want to poop on your parade, but isn’t the
    SCM/RCM/whatevergoddamacbbreviationwereusingtodayforit market kind of
    flooded at the moment? What do you hope to bring to it that isn’t
    already being brought to you in GNU Arch (1|2|Bazaar(-ng)?), Darcs, git,
    and (to a lesser extent) Monotone, subversion, Aegis, svk, cvs, OpenCM,
    Perforce, Visual Sourcesafe.

    This is another brand of software that everyone sooner or later writes
    their own version of, along with text editors, IRC/FTP clients, and
    programming languages, yet no one seems to get right,
    nikolai

    --
    Nikolai Weibull: now available free of charge at http://bitwi.se/!
    Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
    Nikolai Weibull, Jun 27, 2005
    #4
  5. Michael Neumann

    Zed A. Shaw Guest

    Hi Everyone,

    Already replied to you (Michael) offline, but thought I'd throw this out
    there.

    I know I've been totally delinquent in the FastCST development, but I
    promise I am actually working on it, just kind of indirectly.

    * I'm currently polishing off the Ruby/Odeum code so that I can use it
    in FastCST for full text search over code and revisions. This should
    replace just about all the tagging and "revisions follow moves" stuff
    out there. My recent tests show that this approach just rocks.
    * I'm finishing off the CookbooXUL application since I want to provide a
    nice XUL based interface to FastCST.
    * I'm working on the Linda distributed stuff so that I can include
    zero-config setup.
    * And I'm doing a libevent binding so...I can do a libevent binding.

    Anyway, just thought I'd throw that out so folks don't lose hope.
    Anyone who's interested in kicking me in the butt and motivating me to
    actually work with them on FastCST should send a swift kick to my e-mail
    address.

    Zed

    On Tue, 2005-06-28 at 01:11 +0900, Michael Neumann wrote:
    > Hi all,
    >
    > Is there anyone interested in joining a project that aims at creating a
    > Monotone (www.venge.net/monotone) inspired distributed configuration
    > management system in Ruby?
    >
    > Major goal is clean and understandable code, good abstractions and high code
    > quality, from which further ideas could be implemented more easily than is
    > the case for Monotone (at least for me).
    >
    > Ultimate goal of course is the switch from CVS to RCM for the development of
    > the ruby interpreter ;-)
    >
    > Or do we want to let Python win the race? ;-)
    >
    > Regards,
    >
    > Michael
    >
    >
    >
    Zed A. Shaw, Jun 28, 2005
    #5
  6. Michael Neumann

    John Wilger Guest

    On 6/27/05, Zed A. Shaw <> wrote:
    > Anyone who's interested in kicking me in the butt and motivating me to
    > actually work with them on FastCST should send a swift kick to my e-mail
    > address.


    Before I finished that sentence, I expected you to say, "Anyone who's
    interested in kicking me in the butt and motivating me to actually
    work with them on FastCST should send a [fifty dollar check] to my ...
    address." :)

    I thought, "Yeah, that'd do it."

    --=20
    Regards,
    John Wilger

    -----------
    Alice came to a fork in the road. "Which road do I take?" she asked.
    "Where do you want to go?" responded the Cheshire cat.
    "I don't know," Alice answered.
    "Then," said the cat, "it doesn't matter."
    - Lewis Carrol, Alice in Wonderland
    John Wilger, Jun 28, 2005
    #6
  7. Michael Neumann

    Guest

    Re: RCM - A Ruby Configuration Management System

    Michael Neumann wrote:
    > Hi all,
    >
    > Is there anyone interested in joining a project that aims at creating a
    > Monotone (www.venge.net/monotone) inspired distributed configuration
    > management system in Ruby?
    >
    > Major goal is clean and understandable code, good abstractions and high code
    > quality, from which further ideas could be implemented more easily than is
    > the case for Monotone (at least for me).
    >
    > Ultimate goal of course is the switch from CVS to RCM for the development of
    > the ruby interpreter ;-)


    This wouldn't make any sense for the development of the interpreter,
    but for library level code, it would be interesting to consider a
    Ruby-specific approach: rather than model a file in terms of lines of
    text, model it as Ruby class and method definitions, and do all of the
    merging and diffing based on that. What you lose is any ability to
    version other kinds of code, like associated C or YAML files. But you
    gain a much simpler and cleaner model (almost all of the hard, annoying
    problems when writing an SCM have to do with textual diffs; take that
    away and you're left with the fun conceptual part), and a much
    friendlier tool to use: spurious merge conflicts become a thing of the
    past; you can autogenerate meaningful, detailed changelogs; you can
    properly track changes that a traditional SCM would never notice
    (forget file renaming, think about moving a single method or class
    between two files...).

    This is the approach we took when building the Monticello version
    control system for Squeak. The first version, which is currently in
    widespread use (hundreds of packages and several large commercial
    projects), has a very similar design to monotone (unfortunately we
    hadn't seen monotone yet when we wrote it, and so didn't think to use
    public key crypto the way monotone does, which is too bad because it's
    a very cool idea). The second version, which is only now nearing
    usability, is much closer to Bram Cohen's Codeville - which has turned
    out to be a great model in terms of code elegance and potential
    flexibility, although we've yet to see how it works out in real-world
    use.

    Of course it's easier to take this approach for Smalltalk (which
    already has a method-level IDE) than it would be for Ruby, but since
    the SCM only needs to "understand" Ruby code at about the same level as
    RDoc, it shouldn't be all that bad either.

    I don't really expect people to jump on this bandwagon - I realize that
    part of the appeal of Ruby over Smalltalk is that it lives firmly in
    the world of text files, and this would take it slightly away from
    that. But I thought I'd give it a shot anyway. :)

    Avi
    , Jun 28, 2005
    #7
  8. Re: RCM - A Ruby Configuration Management System

    wrote:
    > Michael Neumann wrote:
    >
    >>Hi all,
    >>
    >>Is there anyone interested in joining a project that aims at creating a
    >>Monotone (www.venge.net/monotone) inspired distributed configuration
    >>management system in Ruby?
    >>
    >>Major goal is clean and understandable code, good abstractions and high code
    >>quality, from which further ideas could be implemented more easily than is
    >>the case for Monotone (at least for me).
    >>
    >>Ultimate goal of course is the switch from CVS to RCM for the development of
    >>the ruby interpreter ;-)

    >


    Hi Avi,

    > This wouldn't make any sense for the development of the interpreter,
    > but for library level code, it would be interesting to consider a
    > Ruby-specific approach: rather than model a file in terms of lines of
    > text, model it as Ruby class and method definitions, and do all of the
    > merging and diffing based on that. What you lose is any ability to
    > version other kinds of code, like associated C or YAML files. But you
    > gain a much simpler and cleaner model (almost all of the hard, annoying
    > problems when writing an SCM have to do with textual diffs; take that
    > away and you're left with the fun conceptual part), and a much
    > friendlier tool to use: spurious merge conflicts become a thing of the
    > past; you can autogenerate meaningful, detailed changelogs; you can
    > properly track changes that a traditional SCM would never notice
    > (forget file renaming, think about moving a single method or class
    > between two files...).


    The core of RCM would allow this kind of SCM as it knows nothing about
    files, only entities and their names. In the case of files, the name
    would be the file name, and the entity the content of the file. But in
    the same way, you could version classes and methods.

    BTW, a had a similar idea some time ago, but then realized, that in Java
    or Smalltalk (where you already store classes/methods in the image),
    this is easy, but how would you version this Ruby source code:

    class A
    attr_accessor :a, :b

    eval %{
    ...
    }
    end

    Ruby is simply too dynamic ;-)
    And I'm not sure whether I'd like to store:

    def a
    @a
    end

    def a=(v)
    @a = v
    end

    instead of attr_accessor :a, :b

    Smalltalk evaluates those things only once, and then the original code
    that generated those methods is gone.

    Or how would you split this file as methods, classes etc.?

    class A
    attr_accessor :a

    def b
    end

    C = 4
    end

    You can't simply reorder the statements inside the class!

    > This is the approach we took when building the Monticello version
    > control system for Squeak. The first version, which is currently in
    > widespread use (hundreds of packages and several large commercial
    > projects), has a very similar design to monotone (unfortunately we
    > hadn't seen monotone yet when we wrote it, and so didn't think to use
    > public key crypto the way monotone does, which is too bad because it's
    > a very cool idea). The second version, which is only now nearing
    > usability, is much closer to Bram Cohen's Codeville - which has turned
    > out to be a great model in terms of code elegance and potential
    > flexibility, although we've yet to see how it works out in real-world
    > use.


    Do you know if Codeville is usable for C code? Or is a very regular
    object structure (packages, classes, methods) required?

    > Of course it's easier to take this approach for Smalltalk (which
    > already has a method-level IDE) than it would be for Ruby, but since
    > the SCM only needs to "understand" Ruby code at about the same level as
    > RDoc, it shouldn't be all that bad either.


    I fear, we'd loose some kind of dynamism. Another approach is of course,
    to store diffs with knowledge of Ruby's syntax. Sure, you're approach
    would be much more elegant.

    > I don't really expect people to jump on this bandwagon - I realize that
    > part of the appeal of Ruby over Smalltalk is that it lives firmly in
    > the world of text files, and this would take it slightly away from
    > that. But I thought I'd give it a shot anyway. :)


    Thanks for sharing those ideas with us.

    Regards,

    Michael
    Michael Neumann, Jun 28, 2005
    #8
  9. Michael Neumann

    Guest

    Re: RCM - A Ruby Configuration Management System

    On 6/28/05, Michael Neumann <> wrote:

    > The core of RCM would allow this kind of SCM as it knows nothing about
    > files, only entities and their names. In the case of files, the name
    > would be the file name, and the entity the content of the file. But in
    > the same way, you could version classes and methods.


    Good. But the important thing here is that if your entities are small
    enough, you don't need to worry about automatic merging or diffing
    within the content of the entity. You only need to compare different
    content versions for equality. This makes a *huge* difference to the
    complexity of the SCM. So it's not really about whether you could
    implement something method-based on top of something that was file
    based (clearly you could), but how much work and complexity you can
    avoid by doing it method-based from the start.

    > Or how would you split this file as methods, classes etc.?
    >
    > class A
    > attr_accessor :a
    >
    > def b
    > end
    >
    > C = 4
    > end
    >
    > You can't simply reorder the statements inside the class!


    That's definitely the most challenging problem of this approach. To
    start with you could have an entity (maybe represent it as a singleton
    method called "initialize" on the class, if you like) that would
    gather up all of the "loose" code inside the class def. In most
    cases, I think just keeping this in a single block at the top of the
    class def would be ok. However, you would definitely need to provide
    some structure for cases where ordering was important. One TSTTCPW
    strategy would be to use RDoc-like comments to mark off blocks of code
    that should be treated as individual entities, combined with a general
    inclination on the part of the SCM to keep entities in the same order
    where possible. So:

    class A
    #RCM
    attr_accessor :a
    #/RCM

    def b
    end

    #RCM
    C = 4
    #/RCM
    end

    > Do you know if Codeville is usable for C code? Or is a very regular
    > object structure (packages, classes, methods) required?


    Codeville doesn't require any structure, it's line-based. Monticello
    2 uses the Codeville approach (or at least I think it's the same, we
    came to it independently) of a 2-way merge + independent ancestry info
    for each fine-grained entity, but in Codeville's case the entity is
    the line whereas in Monticello's case it's the method. I do think the
    idea works much *better* if there's a regular structure (how do you
    uniquely identify a line to attach ancestry to it?) but I think it's
    still worth looking at even for a more language-agnostic system.

    One thing that's really cool about this, though I don't know if
    Codeville itself takes advantage of it, is that you can do a perfect
    merge having *only* the two versions you're merging plus their
    metadata. So a formal repository becomes completely unnecessary: you
    never need to look up any previous history. You could build this as
    an extension to RubyGems, for example: each gem version would carry
    around enough info to let it be merged into any other gem version, and
    they could just be emailed or FTP'd or whatever around without any
    special protocol. It's about as distributed as it gets.

    Monticello 1 did this as well, but with a Monotone-style three-way
    merge, which means that you still need enough of a repository to find
    and retrieve the common ancestor.

    Cheers,
    Avi
    , Jun 28, 2005
    #9
  10. Zed A. Shaw wrote:
    > Hi Everyone,
    >
    > Already replied to you (Michael) offline, but thought I'd throw this out
    > there.
    >
    > I know I've been totally delinquent in the FastCST development, but I
    > promise I am actually working on it, just kind of indirectly.
    >
    > * I'm currently polishing off the Ruby/Odeum code so that I can use it
    > in FastCST for full text search over code and revisions. This should
    > replace just about all the tagging and "revisions follow moves" stuff
    > out there. My recent tests show that this approach just rocks.
    > * I'm finishing off the CookbooXUL application since I want to provide a
    > nice XUL based interface to FastCST.
    > * I'm working on the Linda distributed stuff so that I can include
    > zero-config setup.
    > * And I'm doing a libevent binding so...I can do a libevent binding.


    Wow! All that sounds impressive. Please, keep us informed.

    Could you explain more detailed what you mean with: ...tagging and
    "revisions follow moves"?

    Could you give a practical example (e.g. how it would work on the
    command line), so that I can understand it? ;-)

    Regards,

    Michael
    Michael Neumann, Jun 28, 2005
    #10
  11. Michael Neumann wrote:
    > Zed A. Shaw wrote:
    >
    >> Hi Everyone,
    >>
    >> Already replied to you (Michael) offline, but thought I'd throw this out
    >> there.
    >>
    >> I know I've been totally delinquent in the FastCST development, but I
    >> promise I am actually working on it, just kind of indirectly.
    >>
    >> * I'm currently polishing off the Ruby/Odeum code so that I can use it
    >> in FastCST for full text search over code and revisions. This should
    >> replace just about all the tagging and "revisions follow moves" stuff
    >> out there. My recent tests show that this approach just rocks.
    >> * I'm finishing off the CookbooXUL application since I want to provide a
    >> nice XUL based interface to FastCST.
    >> * I'm working on the Linda distributed stuff so that I can include
    >> zero-config setup.
    >> * And I'm doing a libevent binding so...I can do a libevent binding.

    >
    >
    > Wow! All that sounds impressive. Please, keep us informed.
    >
    > Could you explain more detailed what you mean with: ...tagging and
    > "revisions follow moves"?
    >
    > Could you give a practical example (e.g. how it would work on the
    > command line), so that I can understand it? ;-)


    Also, the use of Linda for zero config setup sounds interesting. Care to
    elaborate a bit, or should we wait for the release?
    Joel VanderWerf, Jun 28, 2005
    #11
  12. Michael Neumann

    Zed A. Shaw Guest

    On Wed, 2005-06-29 at 05:42 +0900, Michael Neumann wrote:
    > Zed A. Shaw wrote:
    > > <snip>
    > > * I'm currently polishing off the Ruby/Odeum code so that I can use it
    > > in FastCST for full text search over code and revisions. This should
    > > replace just about all the tagging and "revisions follow moves" stuff
    > > out there. My recent tests show that this approach just rocks.
    > > <snip>


    > Could you explain more detailed what you mean with: ...tagging and
    > "revisions follow moves"?
    >
    > Could you give a practical example (e.g. how it would work on the
    > command line), so that I can understand it? ;-)


    Yeah, basically a common problem is that someone moves/renames a file
    and then changes it, and then behaves as a very poor development citizen
    and checks the changes in without warning people. Everyone else then
    starts using code that has moved out from under them and needs to find
    out what happened to the missing code.

    In CVS you're just out of luck. File go *poof*.

    Other systems have now started giving you their own mv commands so that
    they can track your move operations and then keep the revision history
    moving along.

    What I've done is approached the problem as a generalization of
    searching your source code. I consider the above "dammit, where did
    that file go." problem and other "revision follows move/rename" problems
    as a search problem.

    If I index all of the revisions and all of the current code using
    Ruby/Odeum then you can search for the actual code and simply ask where
    it is in the revisions. So rather than saying, "What happened to file
    blah.h" you would say, "Where did that function in blah.h go."

    I'm still working out the indexing and querying part, but it mostly
    works right now in the code sitting on my computer. Here's an example
    usage:

    fcst find -r "Runner main zshaw"

    Would print out all the revisions with the words 'Runner' 'main' and
    'zshaw' in them, and the files/meta-data mentioning them as well. So,
    if I moved the main method to of the Runner class out, you'd get the log
    messages saying this, the revisions where this happened, and the files
    they moved to.

    In addition this also gives you free indexing of your source and I've
    added a bunch of very nice source searching files to the find command.

    Anyway, that's the really long and unclear idea.

    Zed
    Zed A. Shaw, Jun 29, 2005
    #12
  13. Michael Neumann

    Zed A. Shaw Guest

    On Wed, 2005-06-29 at 05:45 +0900, Joel VanderWerf wrote:
    > Michael Neumann wrote:
    > >
    > >> * I'm working on the Linda distributed stuff so that I can include
    > >> zero-config setup.
    > >>

    > Also, the use of Linda for zero config setup sounds interesting. Care to
    > elaborate a bit, or should we wait for the release?
    >


    This is really rough, but I got a demo of it up and running. Basically,
    I have a small set of code that when it fires up uses Linda as kind of a
    poor man's Bonjour/Rendevous. The thought is that, rather than tell
    FastCST where the repository for Joe is located, you just start it up
    and Joe magically pops up as available.

    This solves a major problem with your typical decentralized RCS.
    Decentralized RCS systems are nice, but people eventually degenerate to
    putting the code on a central system anyway so everyone can find them.
    By having a "auto find/zero conf" system in FastCST you can basically
    collaborate on the code without having to centralize anything.

    At least,that's the idea.

    Zed
    Zed A. Shaw, Jun 29, 2005
    #13
  14. Zed A. Shaw wrote:

    ><snip FastCST Ruby/Odeum stuff>
    >
    >

    Wow. That's cool. Really. I said that out loud when I first read it,
    even though nobody was in the room.

    Doesn't seem, to me, to obviate the need (well, desire) to make mv a
    special operation in your RCS. For example:
    1)It would be nice to view the entire history of a file in one view, but
    more importantly,
    2)How do you solve merging? This is obviously a corner case, but say:
    - Dijon refactors a couple of the methods in the Person class into a
    couple of smaller methods sharing one private method.
    - Hellman renames the Person class to User (and renames the file to
    user.rb), and modifies all the client code.

    Sorry, not sure why I have mayo on the brain.

    Devin
    Hey, at least I didn't make a Kraftwerk reference...
    Devin Mullins, Jun 29, 2005
    #14
  15. Michael Neumann

    Zed A. Shaw Guest

    On Wed, 2005-06-29 at 12:26 +0900, Devin Mullins wrote:
    > Zed A. Shaw wrote:
    >
    > ><snip FastCST Ruby/Odeum stuff>
    > >
    > >

    > Wow. That's cool. Really. I said that out loud when I first read it,
    > even though nobody was in the room.
    >

    Thanks, it's kind of vaporware right now, but I am working on it by way
    of Ruby/Odeum.

    > Doesn't seem, to me, to obviate the need (well, desire) to make mv a
    > special operation in your RCS. For example:
    > 1)It would be nice to view the entire history of a file in one view, but
    > more importantly,
    > 2)How do you solve merging? This is obviously a corner case, but say:
    > - Dijon refactors a couple of the methods in the Person class into a
    > couple of smaller methods sharing one private method.
    > - Hellman renames the Person class to User (and renames the file to
    > user.rb), and modifies all the client code.


    Ah yes, the "industrial autism" corner case. Heaven forbid developers
    should actually have to talk to each other. Oh no, it's the RCS system's
    job to figure out what the developers "mean" (even though computers are
    really, really bad at meaning).

    My philosophy on these weird merge cases is this: The two developers
    who insist on "refactoring" their code wildly without communicating
    should be forced into a room with nothing but dull butter knives and a
    bucket of rock salt. Whichever developer comes out alive gets to have
    their changes in the repository.

    Then again, they could also just get off their ass and talk to the coder
    next to them. Oh, and maybe plan out what they're going to do before
    they do it. That would be great. You know, maybe tell everyone you plan
    to hack the User class today? I hear that daily meetings are really
    good places to mention these things. Something simple like, "Hey, I
    plan to refactor the User class file..." That'd kick ass.

    Oh wait, that would mean developers would actually have to work like a
    team rather than a bag of cats fighting over a moldy tin of tuna.

    Which brings up my other dream feature: Using the Linda ring to tell
    people when Joe Moron starts to mangle code before coordinating with
    others. It's kind of hard to have conflicts and double changes when
    everyone knows you're in there breaking/fixing stuff.

    Anyway, stay tuned while I get things in gear again. Sorry for the
    rant.


    Zed
    Zed A. Shaw, Jun 29, 2005
    #15
  16. Zed A. Shaw wrote:

    >>Doesn't seem, to me, to obviate the need (well, desire) to make mv a
    >>special operation in your RCS. For example:
    >>1)It would be nice to view the entire history of a file in one view, but
    >>more importantly,
    >>2)How do you solve merging? This is obviously a corner case, but say:
    >>- Dijon refactors a couple of the methods in the Person class into a
    >>couple of smaller methods sharing one private method.
    >>- Hellman renames the Person class to User (and renames the file to
    >>user.rb), and modifies all the client code.
    >>
    >>

    >Ah yes, the "industrial autism" corner case. Heaven forbid developers
    >should actually have to talk to each other. Oh no, it's the RCS system's
    >job to figure out what the developers "mean" (even though computers are
    >really, really bad at meaning).
    >
    ><rant/>
    >
    >

    LOL. Okay.

    And to correct you a little bit, a system like CVS/SVN doesn't presume
    to be able to suss out what the developers mean - it asks.

    Also, 'twould be nice to view the entire in one view, but yeah, it would
    require a system you don't want - one that requires manual intervention
    for things like renames. That, and it still wouldn't help the case where
    a class gets split in two, in which case your thing works much better.

    So, point taken.

    In any case, you sound like you need a hug.

    Devin
    Devin Mullins, Jun 29, 2005
    #16
  17. Re: RCM - A Ruby Configuration Management System

    Michael Neumann wrote:
    > Hi all,
    >
    > Is there anyone interested in joining a project that aims at creating a
    > Monotone (www.venge.net/monotone) inspired distributed configuration
    > management system in Ruby?
    >
    > Major goal is clean and understandable code, good abstractions and high code
    > quality, from which further ideas could be implemented more easily than is
    > the case for Monotone (at least for me).
    >
    > Ultimate goal of course is the switch from CVS to RCM for the development of
    > the ruby interpreter ;-)
    >
    > Or do we want to let Python win the race? ;-)


    I'd rather Python won this race, if it meant we could get you to deal
    with the 11 bugs, 4 feature requests and 3 patches on the Ruby DBI
    project.

    Regards,

    Dan
    Daniel Berger, Jun 29, 2005
    #17
  18. Re: RCM - A Ruby Configuration Management System

    Daniel Berger wrote:
    > Michael Neumann wrote:
    >
    >>Hi all,
    >>
    >>Is there anyone interested in joining a project that aims at creating a
    >>Monotone (www.venge.net/monotone) inspired distributed configuration
    >>management system in Ruby?
    >>
    >>Major goal is clean and understandable code, good abstractions and high code
    >>quality, from which further ideas could be implemented more easily than is
    >>the case for Monotone (at least for me).
    >>
    >>Ultimate goal of course is the switch from CVS to RCM for the development of
    >>the ruby interpreter ;-)
    >>
    >>Or do we want to let Python win the race? ;-)

    >
    >
    > I'd rather Python won this race, if it meant we could get you to deal
    > with the 11 bugs, 4 feature requests and 3 patches on the Ruby DBI
    > project.


    Sorry, but I'm no more actively maintaining Ruby/DBI. I should have
    better announced this before. Anyone, who is still using Ruby/DBI, would
    like to overtake the project?

    Regards,

    Michael
    Michael Neumann, Jun 29, 2005
    #18
  19. Re: RCM - A Ruby Configuration Management System

    Michael Neumann wrote:
    > Daniel Berger wrote:
    >
    >> Michael Neumann wrote:
    >>
    >>> Hi all,
    >>>
    >>> Is there anyone interested in joining a project that aims at creating a
    >>> Monotone (www.venge.net/monotone) inspired distributed configuration
    >>> management system in Ruby?
    >>>
    >>> Major goal is clean and understandable code, good abstractions and
    >>> high code
    >>> quality, from which further ideas could be implemented more easily
    >>> than is
    >>> the case for Monotone (at least for me).
    >>>
    >>> Ultimate goal of course is the switch from CVS to RCM for the
    >>> development of
    >>> the ruby interpreter ;-)
    >>>
    >>> Or do we want to let Python win the race? ;-)

    >>
    >>
    >>
    >> I'd rather Python won this race, if it meant we could get you to deal
    >> with the 11 bugs, 4 feature requests and 3 patches on the Ruby DBI
    >> project.

    >
    >
    > Sorry, but I'm no more actively maintaining Ruby/DBI. I should have
    > better announced this before. Anyone, who is still using Ruby/DBI, would
    > like to overtake the project?
    >
    > Regards,
    >
    > Michael


    I think I'm going to cry.

    Dan
    Daniel Berger, Jun 29, 2005
    #19
  20. Re: RCM - A Ruby Configuration Management System

    Daniel Berger wrote:
    > Michael Neumann wrote:
    >
    >> Daniel Berger wrote:
    >>
    >>> Michael Neumann wrote:
    >>>
    >>>> Hi all,
    >>>>
    >>>> Is there anyone interested in joining a project that aims at creating a
    >>>> Monotone (www.venge.net/monotone) inspired distributed configuration
    >>>> management system in Ruby?
    >>>>
    >>>> Major goal is clean and understandable code, good abstractions and
    >>>> high code
    >>>> quality, from which further ideas could be implemented more easily
    >>>> than is
    >>>> the case for Monotone (at least for me).
    >>>>
    >>>> Ultimate goal of course is the switch from CVS to RCM for the
    >>>> development of
    >>>> the ruby interpreter ;-)
    >>>>
    >>>> Or do we want to let Python win the race? ;-)
    >>>
    >>>
    >>>
    >>>
    >>> I'd rather Python won this race, if it meant we could get you to deal
    >>> with the 11 bugs, 4 feature requests and 3 patches on the Ruby DBI
    >>> project.

    >>
    >>
    >>
    >> Sorry, but I'm no more actively maintaining Ruby/DBI. I should have
    >> better announced this before. Anyone, who is still using Ruby/DBI,
    >> would like to overtake the project?
    >>
    >> Regards,
    >>
    >> Michael

    >
    >
    > I think I'm going to cry.


    Great! You're now an admin of the project. But please let me still
    submit gems of postgres-pr ;-)

    Regards,

    Michael
    Michael Neumann, Jun 29, 2005
    #20
    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. Floris van Haaster

    Project management / bug management

    Floris van Haaster, Sep 23, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    1,232
    Jon Paal
    Sep 23, 2005
  2. Replies:
    10
    Views:
    1,220
    Big K
    Feb 2, 2005
  3. Dr Mephesto

    App idea, Any idea on implementation?

    Dr Mephesto, Feb 4, 2008, in forum: Python
    Replies:
    3
    Views:
    702
    Dennis Lee Bieber
    Feb 5, 2008
  4. Replies:
    0
    Views:
    625
  5. Replies:
    2
    Views:
    116
    Mark Gallop
    Aug 9, 2007
Loading...

Share This Page