[Emc-users] takeway from the Wichita meeting
First, I would like to thank Stuart for organizing and hosting this event - it was good to finally meet you guys and exchange views prima facie;) My takeways from the meeting were several: face to face meetings are very valuable, so I'll engage a bit on getting the meeting in Germany going. I also encourage followup meetings in shorter times apart, maybe annually, even if not everybody is able to make it. I hope to speak for all by saying that everybody's takeaway is the others act in good faith. I state that explicitly as I was surprised by the amount of fears being expressed about the 'f word' (not that one.. fork). While I might be a bit pushy on setting things in motion, many of you expressing such fears would be surprised to learn about the amount of arguing _against_ a fork I have done offline. I hope that issue is closed, at least I would appreciate not having to personally deal with it any further. I have asked myself in the past why it is that many contributions fall by the wayside, and my working theory so far was that there might be a rather narrow focus on one's own environment at work. I've learned through the discussion in Wichita there's something different at work, namely a rather high ranking of stability and quality of support being the overriding driving factor. While that clearly is a more commendable explanation, unfortunately the effect is similar: the focus on a single technical aspect - quality at a given point in time - drives other aspects into the background - for instance: even if it is not 100% ready for use, is it an important or at least first step into a new (and eventually important) direction. I hope that a broader range of aspects can be catered for downstream, and I would believe there are some rather easy measures one could take to avoid the large lossage along the way; a starting point would be to differentiate between 'core' and 'contributed' components which are clearly labeled with respect to management of expectations (eg by directory tree and maybe build options like 'enable-contributed-components'). I have visited two more industrial users of LinuxCNC after the Wichita meeting, and discussions with them have reinforced an observation I took away from listening to Stuart and and others what they might want to see in LinuxCNC. This doesnt necessarily match what developers are doing or view as desirable, and the reason for this IMO lies in the composition of the set of developers: I got the impression that none of the more active developers is actually a bona-fide industrial user (i.e. using the stuff in a shop where money is made and folks are employed using it). And, btw, that includes me. While I wouldnt call this an outright defect, I would think this calls for a bit of coordination among industrial users (and potential ones at that too) of LinuxCNC: I do suggest these folks get together, maybe even offline, and coordinate among themselves a prioritized list of features _they_ want to see in LinuxCNC and come back once done in a less isolated fashion; I also suggest that be not done in the usual contexts of mailing list and IRC, the reason for that being the discussion not diverted prematurely by 'this cant be done because of' etc contributions which are likely to happen on the open channels. As for the governance discussion, I am happy to see that the problem has been recognized by the 'old guard' to actually be one, rather than just a pet peeve of the mad Austrian jumping up and down on the European end of an IRC pipe, and I appreciate the willingness to address it. I think the IRC meeting is a step in the right direction, and I will certainly do my part in making that channel and format happen in an effective way. I am not sure if this is sufficient, and I would think some honest reconsideration in a few months might answer this question more clearly. More important, things have started moving; let's review the direction and velocity in due course. - Michael -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] takeway from the Wichita meeting
On 30 June 2013 14:11, Michael Haberler mai...@mah.priv.at wrote: there's something different at work, namely a rather high ranking of stability and quality of support being the overriding driving factor. While that clearly is a more commendable explanation, unfortunately the effect is similar: the focus on a single technical aspect - quality at a given point in time - drives other aspects into the background - for instance: even if it is not 100% ready for use, is it an important or at least first step into a new (and eventually important) direction. I think that there is possibly too much of an expectation that Master must never be broken, but at the same time I can see why that is seen as important, because a lot of people routinely run it. (including me). I have always been of the opinion that creating a new branch was a mistake (and, to be honest, the times I have done that it has definitely been both a mistake and an accident). Having talked to folk at Wichita I am now seeing that this was largely a problem with my understanding of how things are meant to work, and I very much expect to be pushing a new (and explicitly, knowingly broken) tooltable branch this week. Part of my misunderstanding might stem from the fact that JA3 has been stuck in a separate, unmerged, branch for all the time that I have been involved. I haven't noticed anything from an experimental branch get merged. I may not have been watching at the right time. I can see an argument for deleting (or tagging) branches that got merged. (and possibly for tagging the rejected/superceeded branches. To merge threads, is it possible to set up a multi-level access to our Git server, where almost anyone can create a new branch, people like me can create a branch or push to master, and the folk who actually know what they are doing can push to the release branches? I don't think we need to migrate to Github to make ourselves more open to contributions, I just think we need to make it clearer how to contribute. (and to make it harder to lose contributions, and, as a consequence, the contributors). Case in point: http://thread.gmane.org/gmane.linux.distributions.emc.devel/4043/focus=4239 The current 2-ratio gearchange component is rather limited (and not just in the sense it only supports two gears). I know of at least three better versions that have been passed by. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] takeway from the Wichita meeting
On 6/30/2013 7:37 PM, andy pugh wrote: On 30 June 2013 14:11, Michael Haberler mai...@mah.priv.at wrote: there's something different at work, namely a rather high ranking of stability and quality of support being the overriding driving factor. While that clearly is a more commendable explanation, unfortunately the effect is similar: the focus on a single technical aspect - quality at a given point in time - drives other aspects into the background - for instance: even if it is not 100% ready for use, is it an important or at least first step into a new (and eventually important) direction. I think that there is possibly too much of an expectation that Master must never be broken, but at the same time I can see why that is seen as important, because a lot of people routinely run it. (including me). I have always been of the opinion that creating a new branch was a mistake (and, to be honest, the times I have done that it has definitely been both a mistake and an accident). Having talked to folk at Wichita I am now seeing that this was largely a problem with my understanding of how things are meant to work, and I very much expect to be pushing a new (and explicitly, knowingly broken) tooltable branch this week. Part of my misunderstanding might stem from the fact that JA3 has been stuck in a separate, unmerged, branch for all the time that I have been involved. I haven't noticed anything from an experimental branch get merged. I may not have been watching at the right time. I can see an argument for deleting (or tagging) branches that got merged. (and possibly for tagging the rejected/superceeded branches. To merge threads, is it possible to set up a multi-level access to our Git server, where almost anyone can create a new branch, people like me can create a branch or push to master, and the folk who actually know what they are doing can push to the release branches? I don't think we need to migrate to Github to make ourselves more open to contributions, I just think we need to make it clearer how to contribute. (and to make it harder to lose contributions, and, as a consequence, the contributors). Case in point: http://thread.gmane.org/gmane.linux.distributions.emc.devel/4043/focus=4239 The current 2-ratio gearchange component is rather limited (and not just in the sense it only supports two gears). I know of at least three better versions that have been passed by. Regarding your case in point: We should be able to have user loadable (at run time) components -- running everything in user space would make that trivial. That would mean we could have as many gear change components as people cared to write. A broken component would only affect those who tried to use it. It would be marked as a contributed component (use at your own risk). Modularization is good. [BTW (Andy): It was good meeting you in Wichita. I'll remember you as (among other things) the guy who knew what Flemish bond was -- any why it was.] Regards, Ken -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
