2 hours ago, eldrick said:Frequent versions would be far less of a PIA if Cura didn't wipe out machine settings and profiles from one drop to the next.
Normally they should be merged. Already reported these issues? What are your impressions and thoughts on the bug fixing process? ?
On 5/11/2018 at 11:24 AM, Dim3nsioneer said:although it is a bit exeptional that a community member fixes bugs implemented by employed devs ?
I don't find that in the least bit exceptional. I think it rather proves why a strategy of open sourcing software works; you get bugs fixed faster & better.
1
Also; We have 2 full time testers on Cura and 4-5 on system testing. I think you guys are severely underestimating the effort it will take to put more testing into a build.
3
I don't think an LTS release cycle would be a good idea.
I'm a fairly basic user of CURA, still slowly discovering the intricacies of the software and all the options and features hidden in it. I also use it for my business (I'm running a small 3D printing company) and I'm fairly ok with the current release cycle.
I don't take part in the beta-testing due to lack of time to do so, mostly, and I give my heartfelt thanks to everyone who takes time to do it, and even more to those who can and will code fixes for bugs that are detected. I couldn't code to save my life.
I don't see the potential for bugs making through the beta-testing period and into the stable release as being such a problem. First of all, because the people at UM and in the community react very fast when it happens, second, because I can still revert to the previous working version, third, because, no matter how hard or how long you beta-test something, there will always be bugs somewhere.
And major bugs rarely make it past beta. The last bug that I experienced was at the release of 3.3.1 when it wouldn't work if installed on a different drive than C:. It was only mildly annoying, could be worked around by installing 3.3.1 on C temporarily or reverting to the previous version which installed on another drive fine, and, it was fixed within 24h or 48h tops, if I'm' not mistaken. So, it had zero impact on my business.
Software will have bugs no matter how long you test it, simply because you cannot test everything in every situation for every setup. And because there are less testers than there are users, and users will always find things that testers missed, try out things that testers didn't, and so on.
(As a side note, I'll say that anyone who expects 'stuff', be it software or a car or whatever, to work flawlessly all the time is a fool. The first rule of our universe is entropy: 'stuff' will break down and experience malfunction.)
Also, I am interested in new features (CIRCULAR PRIME TOWERS! ...*coughs* Sorry...) but also in stability, which is why I quite like the fact that some new stuff is first released as 'experimental'. You have a working version of CURA, and you can also play with the new stuff, but you're warned that the results can vary from what is expected. I did some tests with the Tree support feature, which is quite nice and saves on support in many cases, but it eats processing power like nobody's business... 'Experimental' features is basically a beta-test under another name.
Finally, if the LTS means that UM looses 25%-50% of development time to maintain and fix older version, then that's one more reason for me to be against the LTS cycle. I'd much rather have them include bug fixes in a new version, along with some new features, and release more often, than have them maintain 2.0 and 2.1 and 2.2 and 3.0 and 3.1 even though they just released 3.2. That kind of thing always seemed a waste of resources to me, in most cases.
Edited by Brulti
2
19 minutes ago, Brulti said:And major bugs rarely make it past beta.
That is, unfortunately, not my experience. All recent versions had issues that were fixed in the next release, but new issues popped up (largely due to newly added features, or "improving" existing features). The problem is that you never get a release that just "works".
The argument for an LTS version is that only bugs get fixed in that "branch", which makes the chance of new bugs being added much smaller, and in time you get a version that is more and more stable. Only one LTS version is maintained at a time, for example based on Cura 3.2. Cura 3.2 LTS would receive no new features, but only bug fixes. At the same time Cura is developed with new features at the same pace as now (maybe somewhat slower due to overhead and backporting fixes). So at some point in the future you would have Cura 3.2.8 LTS and Cura 3.9. All the versions between 3.3 and 3.9 will have had new features, bug fixes, and the inadvertent new bugs, but Cura 3.3 - Cura 3.8 don't receive updates. Cura 3.2.x LTS will have been updated with important bugfixes 7 times. You get a choice which version you use, stability over newest features. This continues until a new LTS release is picked (eg Cura 3.10 LTS)
2
Hi @ahoeben, that's a nice summary of how it could be (dream on Mark, dream on!)
I know of 3 regressions in 3.3 that were not in 3.2. Stuff that used to work but currently doesn't. This should not happen.
Couldn’t you use BCN Cura or Lulzbot Cura as an LTS Version? I mean they usually only do bigger jumps and do bug fixes in between.
I‘m kinda afraid to see Cura branch even more as I think this may release in slower development as everyone starts to do their own thing.
Maybe a first step would be to get more testers by doing more smaller upgrades?
Microsoft Office for example has the insider program.
How much effort/manpower would an LTS Version be if you only merge the bug fixes?
Disclaimer: I‘m not a software dev and therefore can’t judge how much work it takes to maintain such version.
Thinking more about @ahoeben's scheme above, why does it have to be any more complicated than introducing an LTS branch into all of the repos and then having UM commit to testing not only the normal (buggy!) releases but also testing the LTS bug fix releases which would occur when bugs have been found in the LTS release. When sufficient progress has been made on new features/improvements in the non-LTS branch (every 6 months or so), a new LTS release is scheduled. The non-LTS branch would go into feature-freeze and, say, 2 months later, could be pushed into the LTS branch with a reasonable degree of confidence (assuming the community stepped up and helped with the testing).
1 hour ago, ahoeben said:That is, unfortunately, not my experience. All recent versions had issues that were fixed in the next release, but new issues popped up (largely due to newly added features, or "improving" existing features). The problem is that you never get a release that just "works".
Well, obviously our experiences differ. I've been using CURA and my UM3E for close to a year now, and I have yet to experience an issue that is really crippling or disturbing the way I work. So far, all I've experienced were minor annoyances that could be easily remedied to one way or another, even before a fix was issued. YMMV.
Following your line of reasoning, they should just stop development and focus on fixing bugs. Then resume development only once all bugs are fixed. Which would be nice, but that's not a practical solution.
1 hour ago, ahoeben said:You get a choice which version you use, stability over newest features.
Why? Why would I have to chose between being up to date or having stability?
As of right now, CURA offers both, at least in my experience. It works well for me, produces nice prints with my printer, and, if I want to try the new features, I can go down to the 'Experimental' section and give it a try. If that fails, well, I knew beforehand that it was an experimental feature, I've been warned, I can't really complain.
20 minutes ago, cjs said:Maybe a first step would be to get more testers by doing more smaller upgrades?
Microsoft Office for example has the insider program.
I could make jokes or snarky remarks about the 'microsoft insider program', but that would be too easy. ?
20 minutes ago, cjs said:How much effort/manpower would an LTS Version be if you only merge the bug fixes?
Disclaimer: I‘m not a software dev and therefore can’t judge how much work it takes to maintain such version.
As @nallath replied above:
On 11/14/2017 at 11:28 AM, nallath said:I expect it would mean that we lose about 25-50% of our development time if we were to start supporting a LTS version of Cura.
Just a thought: instead of maintaining both stable and experimental versions in parallel, what about doing it in *serial*, sort of?
For example in this way: develop new features and implement bug fixes during the first 6 months of the year, and release these as *experimental* versions.
Then during the last 6 months of the year, only implement bug fixes, but no new features at all. And save all ideas for new features for next year. Of course you would discuss new ideas internally, collect remarks from customers, streamline all these concepts, unofficially do a few internal tryouts on various concepts, etc... But just don't release anything of it.
In this way, the last six months of the year would serve as a sort of "reflection time", to thoroughly think things over, and to do some fundamental research. While at the same time making the existing stuff more stable. Also during the last six months, time could be spent on improving the build-in pop-up help, so that each function gets more clear to users. A lot of problems seem to come from users not knowing that some options exist, or not knowing how to optimise them for their particular model.
In this way, by the end of each year you would have a really stable version. One that is good enough to last until the next year, for most users. This effectively gives a long term stable release for production work.
What would you think about something like this?
13 hours ago, nallath said:open sourcing software works
Yep, Cura is really a good prove and surely it is often not easy to convince supervisors about this principle of development.
12 hours ago, nallath said:I think you guys are severely underestimating the effort it will take to put more testing into a build.
Hope I'm not meant with this. I saw the effort in person and during plugin development many issues have been found, which I didn't see before. It is hard to explain, but the issues which have been found were helpful to ensure stability and also the level of needed software quality to get something passed was high.
I think what most people underestimate is how difficult it is to find bugs across all the lines of code.
I only coarsely read all the following posts and think it is great that we began a discussion like this. It underlines that people care about stability (maybe more then before, because of the growing usage of 3d printing for business) and that people like to share ideas. In my opinion UM shouldn't be offended in any way. In my opinion I would even support this movement and give people a feeling of how difficult it is. Nothing is better then practical experience... I would poeple just play with this hard task.
Just hope that people begin to move things soon, instead of complaining all the time ?
Just to lower a bit the seriousness: I love Cantuccini recently ?
Hope there is less anger in the air now ?
Beautiful. No stability problems anymore ?
MariMakes posted a topic in UltiMaker Cura,
ArunC posted a topic in UltiMaker 3D printers,
Recommended Posts
thopiekar 46
Oops, play on words again. ?
But seriously now.. Are there reasons why a community version would require a different name? Cura is no (TM) in any way, right? ?
Link to post
Share on other sites