Jump to content
Ultimaker Community of 3D Printing Experts

thopiekar

Member
  • Content count

    151
  • Joined

  • Last visited

Community Reputation

10 Good

About thopiekar

  • Birthday 12/06/1991

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. thopiekar

    CDK - CuraDevelopmentKit (unreleased)

    Quick Update: The minimal flavour can be built easily now. The development will flavour will include nano as command line editor and qtcreator for advanced designing and coding work. Building it works on Ubuntu amd64 without issues, OSX should work too (🤞), but can test because of a leak of hardware and software. Currently I'm trying to get it built for Windows amd64, but that really takes a lot of time whereas I only have 10min effectively recently. Also will rename the repo soon and make it open when I made an upgrade to GitLab and I have no security concerns anymore. Cheers!
  2. thopiekar

    Cura stability - the argument for an LTS release cycle

    Yep, Cura is really a good prove and surely it is often not easy to convince supervisors about this principle of development. 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 😜
  3. thopiekar

    Cura stability - the argument for an LTS release cycle

    Normally they should be merged. Already reported these issues? What are your impressions and thoughts on the bug fixing process? 🙂
  4. thopiekar

    Cura stability - the argument for an LTS release cycle

    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? 🙂
  5. thopiekar

    Cura stability - the argument for an LTS release cycle

    Meh, a simple unbranding of Cura-vuild-environment would be enough. On the splash screen it would be enough to call it either simply Cura CE or Cura Community Edition. Would rename CuraVersion.py.in into CuraConstants.py.in and set there the default theme. So within CMake and buildtime we can choose the community theme. From my point of view this is done. Already had unbranding in mind for my PPA, because people might think it is UM driven, but it is not. So how many people do you think could we get together?
  6. thopiekar

    Cura stability - the argument for an LTS release cycle

    I know. I never said that a lot of effort is needed for it. It really depends on how much the community is willing to do in terms of development and testing. Ultimaker does a lot to test their software and the people employed are doing very good. However, it seems from the feedback here that this is too less. Building an infrastructure, like @smartavionics and I already brainstormed on, really need more people to keep it up. I can also imagine that UM could jump on and help out with computing resources, but first, it needs a proof of concept and this again needs human resources. This is finally from my experience, what will fail in the community I guess - there are simply too few people, who want to get active and get (big!) things moving. That is, by the way, the reason, why I'm stepping back from community work (very) slowly.
  7. thopiekar

    Cura stability - the argument for an LTS release cycle

    Well, the solution I had in mind is again a bit over complexed, but if you have the resources, then it is the most elegant way I think. I would personally never merge inthings into -next too early because if something is going wrong you need to get the code out of those -next branches, before they get merged into newer releases and consequently master. Well, the community can either wait for a solution by UM or just kick asses, set such an infrastructure up and prove this kind of CI setup is really needed Of course, you can wait for a solution, but do not complain that nothing is happening (or seems so). . People in the community often underestimate the power they have to influence. Only thing to do is finding people with the same interest and push hard to what you want. However, that is my impression.
  8. thopiekar

    Cura stability - the argument for an LTS release cycle

    I think basically all people are the same. Beginners are quite the same as business customers. Once they get disappointed you are losing them (worst case) forever, because of the disappointment which gets associated with the product based on their experience. Actually everyone wants stable software, but most people get tempted by new features. I'm the best example: everytime I f**k up my computer (oh, that's already a while ago) I tell myself: I have to use an LTS or Debian stable. But it takes around 1 week until I begin to upgrade again. Yesterday night I took some time before sleep to think about it. I branch layout I have in mind is even more complex then you suggested. Together with CI I would create for every minor version (eg. 3.2 and 3.3, etc.) a branch with a -next suffix where every change is included, which is not well tested and release. Whenever a serious bug is there, I would create a branch, eg. 3.2-CURA{ticketnumber} or *-GITHUB{issuenumber}. Whenever something is pushed there, a new build is triggered, which builds a new installer for windows or AppImage for Linux. To ease people to report is has been fixed there, we could add an plugin, which adds an button below the toolbox area. This one could have too selections, eg. 👍 and 👎. Culture-wise I doubt there are many people who don't know what it means. As soon as a test build hits more than 10 tests, with a ratio of more than 9:1 successful fixes, the branch could be automatically merged into the brnach of the minor version. The art of all of this is to care about finding the bug at the oldest version. Then all versions upwards can benefit of it. At this point your suggestion of defining what a LTS is could kick in and define that eg. 3.2 is the current LTS. @Anders Olsson No, the question was not meant for you but still interesting to hear about your impressions how the Cura development does recently. Regarding your quality problems, I would recommend to slice your model and compare the GCode, highlight the changes and differences and report it on GitHub or the forum here, so someone can help. As a conclusion I see understand now, why the development goes too rapidly for you. Currently I don't have much time anymore to help out, but maybe I can help somehow in a different way.
  9. thopiekar

    Cura stability - the argument for an LTS release cycle

    Good point. The few people are then maybe also not so sensitive to errors.. So when thinking of the workflow when fixing bugs or adding new features. What would you change? Do you already have a strategy in mind? I wouldn't differentiate between the community and business/end-users. What actually counts here the most, is that your suggested stable/beta/dev flavours need to be deployed to the users more easily and I think this can be easily done(!).
  10. thopiekar

    Cura stability - the argument for an LTS release cycle

    Hmm, I understand the benefits, but it is always a question of time, whether it is worth the effort - just like @nallath mentioned before. Because I know him a better, I'm sure he has a good estimation based of his work experience of how much time in addition it would take. Is your experience of disappointments around Cura based on other people, too? I personally don't hear much of this kind of feedback. (Maybe the question should be asked whether we couldn't make bug reporting easier, so we get more and earlier feedback on found bugs?)
  11. thopiekar

    Cura stability - the argument for an LTS release cycle

    I personally don't think an LTS makes sense. The reason why there are LTS versions in Ubuntu is that packages are maintained for a long time while having stability and security in mind. So in my opinion, if someone likes to have an LTS-ish feeling while using Cura, she/he should simply pick the last release with a patch version >= 0. Security-wise Cura is not that much connected to internet services, that you need to worry about breaks there. From my feeling stability issues are taken always serious at Ultimaker, so it is always a question of time until a fix is there and until then you can always redownload the previous version from the website. If people (or the community itself) think it is not stable enough, then they can also bake their own version and cherry-pick the fixes only. But I doubt that there is a group (large enough), which has time and the capacity for it. @Anders Olsson: * Fixing bugs is not always as trivial as it sometimes seems. In my opinion, you need to find a red line and skip fixing bugs from a prioritised list, because the fixes, which have been found, need to be shipped to. Therefore I think it is fine just to wait for the next patch version or major release. * The default is the simplified view, which does not provide access to all the features. I personally wouldn't like to add more buttons there. Once people will decide to add more options there, then all the other use-cases will come up and the simplified view will get the new advanced view. Comparing Cura to other professional software, I would say that once people want to print more complex things like this, they simply need a training in using Cura. Cura is a professional 3D-slicing software and giving up all the great parameters and options it has would be stupid. I can imagine a lot of effort would be invested into finding relations between the settings, a lot of assumptions would be done on the customer, which maybe don't happen or fit, and, finally, the end-user would be disappointed, because something is not printable. The only thing I agree about is something that @smartavionics kind of mentioned: longer beta/test cycles. I think it is no secret anymore that Ultimaker creates daily nightly builds. I see no reason why releasing them in public (excluding internal secrets) would be an issue. The sources (cura-build-*) to build Cura are already public. In theory, everyone could build a nightly version on their own, but that is less comfortable, so most potential testers keep using either the last release or go for the early beta. (Guess that is enough from my side for now 😅)
  12. thopiekar

    Autodesk Inventor Plugin (0.1.5)

    Haha, thanks @tetrahedron Just let me know if something does not work. If I don't get any feedback from someone, I can still overlook something. The better the documentation of the symptoms of the bug and the stronger the argumentation why fixing it counts (for all people), the earlier I'll take some time on it. Again, thank you for your efforts, because it seems you only registered for the forums here to join this thread! 😃
  13. thopiekar

    Autodesk Inventor Plugin (0.1.5)

    Great! I'm in talks currently to get this plugin into the plugin browser, too. https://thopiekar.eu/download/CuraInventorPlugin-0.2.2.curaplugin There are no big differences regarding features, but some stability fixes inside. @StS Do you (still) face the issue with 3.3.1? When doing my own tests here with the package above (v0.2.2) I didn't noticed any issues using 3.2.1 and 3.3.1. Or do @tetrahedron and you belong together and the issue has been solved? Regards and thank you for giving feedback here!
  14. thopiekar

    CDK - CuraDevelopmentKit (unreleased)

    Yes, but more advanced. Checks whether the JSON is valid, whether there is a __init__.py in the root directory of the plugin, etc. thopiekar@home:~$ python3 cpo.py -h usage: cpo.py [-h] [--source SOURCE] [--exclude EXCLUDE] [--downloaddir DOWNLOADDIR] [--build BUILD] [--destination DESTINATION] [--variant {binary+source,binary,source}] [--compression {none,zlib,bzip2,lzma}] [--optimize {0,1,2}] [--gitargs GITARGS] optional arguments: -h, --help show this help message and exit --source SOURCE, --src SOURCE, -s SOURCE Location of the source folder --exclude EXCLUDE, --excl EXCLUDE, -e EXCLUDE Location of the source folder --downloaddir DOWNLOADDIR, --dldir DOWNLOADDIR, -dd DOWNLOADDIR Location of the download folder --build BUILD, --bld BUILD, -b BUILD Location of the build folder --destination DESTINATION, --dest DESTINATION, -d DESTINATION Location, where to place the resulting package --variant {binary+source,binary,source}, --var {binary+source,binary,source}, -v {binary+source,binary,source} Variant of build --compression {none,zlib,bzip2,lzma}, --comp {none,zlib,bzip2,lzma}, -c {none,zlib,bzip2,lzma} Package compression --optimize {0,1,2}, --opt {0,1,2}, -o {0,1,2} Location of the build folder --gitargs GITARGS, -ga GITARGS git arguments I'm close now to build a plugin package using GitLab on each commit I do. This way it is easy to distribute these packages to testers.
  15. thopiekar

    CDK - CuraDevelopmentKit (unreleased)

    @gr5: Good catch! Just posted the wrong URL. The correct one is: https://thopiekar.eu:5443/Cura/cura-build-environment/pipelines @ahoeben: By "building" I meant creating a .{cura, um}plugin file. Also have a script lying around here called "CuraPluginOven", short CPO. It is a full command-line tool, so you can either pass a local or a remote git repo and it builds a plugin file. Also comes with come checks, whether all conventions are met. This could be added in theory, too. By when writing the first post I had the situation in mind when you need additional (3rd party) Python modules (C-extensions). Also as far as I remember, I managed to rebuild Numpy and SciPy in the early days (approx 3 months before). So Cura could be fully OpenSource *without* Intel MKL blobs. In short: The bundle you can download is a rootstrap, which is fully usable with user-rights. Had yesterday a talk at the booth in Hannover and got feedback, that people might be interested in this here.
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!