ianpaschal

@ahoeben Difficult to know without the logs but it looks like either the plugin is corrupted or it's the wrong version for this version of Cura. Can't really diagnose without knowing Cura version and logs and such.

This is true, but I also don't see it as a problem. You yourself say it's good in terms of quality of the code. Also of course it's a limitation in the real world. That's the case with everything. There's social causes I'd like to help lawyers fight for but criticizing their process is not that and without a legal background the best I can do is cheer from the sidelines. I'd also really love to cook alongside a world class chef but I am not much help. That's life, and that's ok. There are still non-coding ways to contribute though. I brought up the other two because everyone is listing their "I know a thing or two about code" credentials, to which the obvious response is: participate then. I really like what you finished with though... This is a case where it is really helpful to know what users want. This is why I say of course Cura is always open to feedback. Granted it's up to our product owner to chart a course for the software, but I know he wants to know what people want. But the discussion of features and purpose is of course a separate issue to the actual nitty gritty of development process which is what I was under the impression Ricky initially felt was not going well.

That's why Cura is free, though. Everyone can use it, for free, with any printer they want. OK, you might feel that way, but I don't think most people do. This is also a whole other issue than the day-to-day development workflow. It sounds like you have a problem with a for-profit enterprise backing an open-source project which is totally unrelated to CuraEngine development specifics. No one would disagree with you that such a company should have a conscience, but I think UM actually has a pretty great reputation in that regard. Largely because of, again, things like making our slicer open source and working with competitors' hardware. That's true, and to be honest, I'm a fan of the development model you mentioned. But the point is that Git workflows don't magically change code quality. If starting a new project we might consider a different model. Some of the private internal UM repositories do use this model. But applying it to CuraEngine doesn't make the code better by default. Merging into a dev branch and then merging into master makes no difference if the review process was not good, nor will it address the fact that you have the idea that the whole architecture of the code is wrong. Again, if you are concerned, there's two things you can do: Read and review pull requests to point out code which you feel is overly complicated, and secondly, start a refactor to simplify it. These actions are not at all dependent on the branching model used. And if you feel that you don't want to contribute your time to the project in these ways (participating, contributing) because it doesn't fit your philosophy, that's fine too. But then to spend lots of time complaining why it doesn't suit you absolutely is "concern trolling."

@Ricky Maybe I shouldn't have used the term "concern trolling" if people are not familiar with it but I'm not calling you a troll really. I'm refering to the general nature of online threads that are a big discussion about "how bad things are." They accomplish nothing. My statements stand; if you're concerned about the quality of CuraEngine; do something about it. Participate. Start a refactor in the name of Occam. I guarantee you we'll jump on that. That's why it's an open source project. Also, stop bringing up liberals. That has no place in this conversation and at least from my end only makes it hard to take you seriously. Politics out.

As an open source project, Cura is always open to feedback. That being said, after letting it sink in, this feels more like concern trolling than constructive feedback. If anyone is so concerned that the development is "going in the wrong direction" (the horror!), there's two very simple steps to take: 1. Participate in code review. See something that looks hacky or overly complicated? Say something. 2. Begin a refactor. We can all hum and drum about razors and philosophy but it doesn't really mean anything if there's not code behind it. I'm leaving off 3. Switch development model. There are pros and cons to any model we bring up here, and they will all work provided that the above two things are done. If the code review isn't done correctly, it doesn't matter if stuff gets merged through a dev branch first, and if the review is done correctly, it shouldn't matter. With any statement ever, I'm sure someone can disagree but it doesn't really make a difference. The beauty of open source is that anyone who is concerned with the process can make a measurable improvement to it by simply participating. To any who do, Cura team thanks you!