On Wed, 22 May 2019 at 01:06, Rod Webster <[email protected]> wrote:
Chris, it seems there needs to be a process to look at new work becasue > what you are saying is if you are not in the inner sanctum, you can't > contribute. > But if you are in the inner sanctum, you don't have the time. Have you ever seen "The Wizard of Oz"? When I first started with LinuxCNC I imagined that, in the background, there was an inner Cabal of core developers who chatted amongst themselves and had a plan. I have realised since that that probably isn't the case. I asked for, and was given, push access to the LinuxCNC Git quite early on. I suppose if anyone has the keys to the Inner Sanctum it is Seb, as he can add ssh keys to the github to allow push access. (It may be that I can do this, I don't know my way around the system well enough to be sure). But I have never felt myself to be a member of the Inner Sanctum, I am not even a proper programmer. To merge someone else's work you need to feel competent to review it. And to review it you need to understand that part of the LinuxCNC system. I am fairly happy to review and merge HAL components, and updates to the Hostmot2 drivers, but the TP and interpreter are a mystery to me. I can't even comfortably read C++. Jepler seems to have an uncanny ability to read through code and spot bugs without testing. (I can't even see those bugs in the code as I am writing it). This led to jepler becoming the de-facto LinuxCNC code guardian, but I don't think it was a job he wanted or relished, and this might be what has pushed him to back away from the project. For a feature to be merged, a number of things need to happen: 1) The author needs to ask for it to be merged. 2) It needs to be mergeable (ie apply without conflicts, sorting out merge conflicts in unfamiliar code is something that almost nobody feels comfortable taking on) 3) There needs to be some expectation of ongoing support from the author. (This is not always the case, look at the Bezier curve G-codes as an example) 4) The person merging it needs to feel confident that it won't break anything, or if it does, that it will get fixed. I am not defining _policy_ here[1], these are the things that need to be true before _I_ will merge something. I don't want to merge a feature, find that it breaks LinuxCNC, that the original author has moved on, and that I am committed to trying to sort out the mess for an indeterminate time. You mentioned "multispindle". I merged that because all of the above was true, specifically that I was prepared to support the changes indefinitely. There are other features that I have worked on (sometimes extensively) such as a tool database in SQLite and the G71 / G72 lathe roughing cycles that I haven't merged for fear of destablising bits of the code I didn't fully understand. On to specific features: If we look at the list of pull-requests: https://github.com/LinuxCNC/linuxcnc/pulls You will see that reverse run is not there. And some of the things that are there are authored by people who already have push rights, so could merge the code themselves if they chose to. Some stuff gets put in experimental branches rather than being made in to a pull request. This can make sense, but then the author really will have to work hard to persuade others to try it out. (Or it needs to be a feature that has a clear use and interested trial users, such as Dewey's "External Offsets" which started off that way) [1] I don't set LinuxCNC policy. The Inner Cabal set policy, and they don't exist, ergo no policy. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1916 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
