This is a short summary of Andy's and my discussion of the issue at Wichita,
and several longer offline discussions before that. It sketches how in the
future the handling of tool information (and likely all persistent data) will
be handled in LinuxCNC.
1. the storage and retrieval of all
Gentlemen:
Andy has taken a large bite of work - tool handling in LinuxCNC - and has made
very quick progress on it. He deserves all the support from us he can get; we
do not have enough folks taking a larger-than-average bite and actually deliver
on it.
I also note that part of that work is
On Sat, 29 Jun 2013 18:15:54 -0500
Charles Steinkuehler char...@steinkuehler.net wrote:
So what do I think needs to change? Well, let's start with what
exists now, which I see as:
Tier 1) Anointed LinuxCNC developers with push access to
git.linuxcnc.org.
...
Tier 2) People who have
however it shakes out, there needs to be some clear direction on the best
practices for managing development on branches and forks, how pull requests and
merges should be done, who can and will review and merge them, etc.
I'm heavily in favor of using a service like github or bitbucket because
Ok so I think this code is well enough tested, and the comp files also
includes the documentation.
What do I need to do to get this integrated into the codebase.
I have a branch on github with my changes. I can provide a patch if
necessary. https://github.com/OKComputers/linuxcnc
Thanks,
On Sun, 2013-06-30 at 12:28 -0400, Matt Shaver wrote:
On Sat, 29 Jun 2013 18:15:54 -0500
Charles Steinkuehler char...@steinkuehler.net wrote:
So what do I think needs to change? Well, let's start with what
exists now, which I see as:
Tier 1) Anointed LinuxCNC developers with push
On 06/30/2013 07:45 PM, Curtis Dutton wrote:
Ok so I think this code is well enough tested, and the comp files also
includes the documentation.
What do I need to do to get this integrated into the codebase.
I have a branch on github with my changes. I can provide a patch if
necessary.
While I'm a LinuxCNC user (and a relatively new user at that) and not a
developer, and as such may not be entitled to any opinion on the
development process, I nonetheless have a few. :-)
Good that's what we want.
I'd first like to say that I'm very appreciative of the work that's
This was a tabled item from the last meeting.
The consensus seemed to be the idea had merit but discussion was needed.
Micheal's proposal was a 'machiekit' package that included:
Machinekit would be HAL+RTAPI+NML replacement (zeromq+protobuf)
The idea here is that HAL is a great piece of code
Andy, Michael,
The network accessibility of the data store and the associated API is
key to both providing and understanding the functionality that this
approach could provide.
Is there a proposed design document that lays out the API?
Dave
Date: Sun, 30 Jun 2013 22:25:20 -0700
From: d...@calypsoventures.com
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] toolstore discussion notes: Andy/mhaberler
Andy, Michael,
The network accessibility of the data store and the associated API is
key to both
11 matches
Mail list logo
