Andy Thanks for taking the time to explain. From where I sit, I've seen a few experimental branches find their way into the main code. eg External Offsets which i did a lot of work with Dewey testing his failed plasma config. I also observed an attempt to merge the reverse run branch that was reverted in November last year. I don't think there was pull request sitting there at that time. So its hard for users to get their head around how to make contributions.
I've pored through the TP code a couple of times but am no where near competent enough to tackle changes there and don't understand git enough. Nor do I really have the time while running a business. I suspect the lack of formal processes around dealing with those pull requests may be a bit of a road block. One of them is 3 years old next month... Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Wed, 22 May 2019 at 22:03, andy pugh <[email protected]> wrote: > 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 > _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
