Loading ...
Sorry, an error occurred while loading the content.

Re: [frontierkernel] Re: Source code control and object databases

Expand Messages
  • Jake Savin
    ... I can only speak for myself of course, but I m mainly interested in working on two things: Manila and supporting code, and tools to make that work easier
    Message 1 of 21 , Feb 23 4:39 PM
    • 0 Attachment
      On Tue, 23 Feb 2010 19:57 +0000, "dwiner" <dave.winer@...> wrote:
      > Here's something to think about -- of the four of us, Brent, Andre, Jake
      > and myself -- I'm pretty sure I'm the only one actually doing work in
      > this area.
      >
      > Are you guys saying you will do work on odb-resident code if there's a
      > source control system?

      I can only speak for myself of course, but I'm mainly interested in working on two things: Manila and supporting code, and tools to make that work easier and more productive. Hopefully if we can get some momentum going, I'm also interested in helping serve an organizational function for contributors.

      As far as tools go, I want to make it easier to develop odb-level code in the Frontier IDE, and to integrate with modern infrastructure that's often taken for granted in other projects, and which may be (is?) missed here.

      I kicked off this thread in part to start thinking and talking about whether any of that work should happen here, or if it's better off elsewhere. Obviously I would rather build on whatever foundation that already exists, if possible.

      > I already have very spare time for working on this stuff, and I'm not
      > inclined to do anything to add overhead unless I'm reasonably (bordering
      > on absolutely) sure there's a payoff.

      I'm totally with you on here. Development tools and source code management should exist to make it easier to work on the project, and to remove barriers, not put them in the way. (Believe me, I've seen it go the other way plenty of times, and it's not pretty.)

      While I was still at UserLand, I had put together some tools that worked well for me, for managing change-lists and doing large diffs. I found that I got a huge productivity boost from not having to manage every part by hand at every step, and being able to clearly see large changes at a high level. I had a longer term goal of getting a good SCM system integrated into my workflow, but didn't get there.

      As part of getting my brain thinking about coding again, it seemed like a relatively safe place to start working, since failure to deliver won't break or block others, whereas success could help infuse some excitement around developing in UserTalk again, and boost at least my own, if not others' productivity on the project.

      > A decent payoff would be having Brent, Andre and Jake actively working on
      > odb-resident code.

      As I said, I want to do some work, and since I'm not a particularly proficient C/C++ coder, odb-resident UserTalk is where I'm going to be most productive and effective.

      Regards,
      -Jake
    • dwiner
      That s what I thought. I ve released a copy of manila.root, but it still needs to be packaged as a GPL d thing and if you can come up with a way to manage
      Message 2 of 21 , Feb 24 2:12 PM
      • 0 Attachment
        That's what I thought.

        I've released a copy of manila.root, but it still needs to be packaged as a GPL'd thing and if you can come up with a way to manage source code for it, that would be great.

        http://frontiernews.org/2010/02/03/manila-root/

        As far as I know the only supporting code for Manila that's not already in the OPML Editor release is prefs.root. I've run manila.root in the OPML Editor and it appears to work without problems. All I've done is made it a Tool so it can be managed by the newer Tool-managing code. If you recall, manila.root predated tools.

        So I think you should take charge of manila.root. The goal would be to fix bugs and modernize it, make it more useful in a 2010 context.

        How does that sound?

        Dave


        --- In frontierkernel@yahoogroups.com, "Jake Savin" <me@...> wrote:
        >
        > On Tue, 23 Feb 2010 19:57 +0000, "dwiner" <dave.winer@...> wrote:
        > > Here's something to think about -- of the four of us, Brent, Andre, Jake
        > > and myself -- I'm pretty sure I'm the only one actually doing work in
        > > this area.
        > >
        > > Are you guys saying you will do work on odb-resident code if there's a
        > > source control system?
        >
        > I can only speak for myself of course, but I'm mainly interested in working on two things: Manila and supporting code, and tools to make that work easier and more productive. Hopefully if we can get some momentum going, I'm also interested in helping serve an organizational function for contributors.
        >
        > As far as tools go, I want to make it easier to develop odb-level code in the Frontier IDE, and to integrate with modern infrastructure that's often taken for granted in other projects, and which may be (is?) missed here.
        >
        > I kicked off this thread in part to start thinking and talking about whether any of that work should happen here, or if it's better off elsewhere. Obviously I would rather build on whatever foundation that already exists, if possible.
        >
        > > I already have very spare time for working on this stuff, and I'm not
        > > inclined to do anything to add overhead unless I'm reasonably (bordering
        > > on absolutely) sure there's a payoff.
        >
        > I'm totally with you on here. Development tools and source code management should exist to make it easier to work on the project, and to remove barriers, not put them in the way. (Believe me, I've seen it go the other way plenty of times, and it's not pretty.)
        >
        > While I was still at UserLand, I had put together some tools that worked well for me, for managing change-lists and doing large diffs. I found that I got a huge productivity boost from not having to manage every part by hand at every step, and being able to clearly see large changes at a high level. I had a longer term goal of getting a good SCM system integrated into my workflow, but didn't get there.
        >
        > As part of getting my brain thinking about coding again, it seemed like a relatively safe place to start working, since failure to deliver won't break or block others, whereas success could help infuse some excitement around developing in UserTalk again, and boost at least my own, if not others' productivity on the project.
        >
        > > A decent payoff would be having Brent, Andre and Jake actively working on
        > > odb-resident code.
        >
        > As I said, I want to do some work, and since I'm not a particularly proficient C/C++ coder, odb-resident UserTalk is where I'm going to be most productive and effective.
        >
        > Regards,
        > -Jake
        >
      • Jake Savin
        Sounds good, Dave. I agree with the high-level goals you stated. I d also like to fix some long-standing bugs, and do some work to make it easier for sysadmins
        Message 3 of 21 , Feb 24 8:33 PM
        • 0 Attachment
          Sounds good, Dave.
           
          I agree with the high-level goals you stated. I'd also like to fix some long-standing bugs, and do some work to make it easier for sysadmins to maintain servers with more than a few sites.
           
          I would hope that the folks on this list will speak up if anyone has fundamental objections. (I certainly also welcome any other input.)
           
          Thanks,
          -Jake
           
          On Wed, 24 Feb 2010 22:12 +0000, "dwiner" <dave.winer@...> wrote:
           


          That's what I thought.

          I've released a copy of manila.root, but it still needs to be packaged as a GPL'd thing and if you can come up with a way to manage source code for it, that would be great.

          http://frontiernews .org/2010/ 02/03/manila- root/

          As far as I know the only supporting code for Manila that's not already in the OPML Editor release is prefs.root. I've run manila.root in the OPML Editor and it appears to work without problems. All I've done is made it a Tool so it can be managed by the newer Tool-managing code. If you recall, manila.root predated tools.

          So I think you should take charge of manila.root. The goal would be to fix bugs and modernize it, make it more useful in a 2010 context.

          How does that sound?

          Dave

        Your message has been successfully submitted and would be delivered to recipients shortly.