I’m not a developer nor an expert tester, but I do run Windows, so I’m happy to join the program and help find bugs. Thanks for doing this.
1 Like
Part of the problem is knowing which release bugs exist in. A bug gets raised against master, or against a release version, and people won’t necessarily check every build to see if it’s present. Most of the time it just gets fixed in development and people move on.
If a major issue exists before we release, we will usually try to fix it. Probably most of the bugs in 3.6.0 haven’t been found yet, so the release notes don’t really make sense to keep this info.
All-in-all it’s a lot of admin, and nobody wants to volunteer for admin.
One thing you can do though is look at the 3.6.1 milestone to see what’s planned for the next minor release (these will usually be the big issues) or the 3.8 milestone for issues planned for the next major release. Bear in mind that most of the issues planned for 3.8 probably never existed in 3.6 because they’re problems with new development.
2 Likes
I understand that’s just a hobby project. But if this topic is call for feedback, people won’t be happy when time they spend on investigation, isolation, documentation of issues will result only in github autoclose.
It’s linked in the mentioned github issue.
1 Like
Users are never in the dark as they can follow what happens in the issues section.
If someone wants to make the effort to put all that information together, that would be very welcome. We have a bunch of Windows users and not many devs/contributors.
We already have too many communication channels. And what is major for one user isn’t for another. We have issue trackers, mailing lists, chat rooms, forums, and probably more.
3 Likes
That’s not a reasonable approach imo. The issue tracker is meant for developers, not everyday users wanting to know if there are limitations or known problems when using their software. It’s not uncommon to have such a list as a part of the release notes as @danny argues.
As for the argument ‘but the developers only run Linux’, I am on the fence. In my experience as a Windows user and developer of RawTherapee, it hardly costs any extra time to test a Linux build in a virtual machine. I also have a virtual Windows 7 and Windows 8 instance available for testing fwiw. I haven’t bought licenses, but I don’t have to, to be able to test.
So why wouldn’t the other way around work as well? It’s understandable to focus on development for one platform, but it’s not hard to properly support more. It’s perhaps less time consuming than people think.
Its not an approach, its just the way it is. If someone wants to change that and do all this admin work, it is welcome, as I already said.
Available time.
Again, this is just an admin task, and anyone who wants the situation to change is free to volunteer for this task. Most developers much prefer to do development. New contributors are very welcome.
Anyone?
Again, though, developers still have to want to do that, and to know how to resolve issues in a Windows environment. We are not a commercial entity and most of us are on Linux precisely to escape the issues that having a Windows environment entails. As a Windows user and developer of RawTherapee you sound like someone who might be able to help us with this.
1 Like
I can test on Windows. I have Windows, although most of the time I don’t use it, but in a few days I will finish a project that requires me to run Debian, and after that another project seems to be coming that requires me to use Winodws again.
I have tested darktable for Winodws on a laptop and a desktop like 2 weeks ago and found bugs, in concerns opencl and performance. Trying to find out more about the nature of the bug, I downgraded to earlier versions of dt for Windows and found out interesting things… I think performance issues on Windows are module-dependent…
I think there are lots of users that use dt for Windows but it’s probably not so easy to make them test… look around on Instagram… there are also young ladies and of course gentlemen… I mean like 14 or so… finding/reaching them here is difficult…
I can compile on Windows, too.
1 Like
I think one of Windows painpoints is non-ascii characters… so gotta test if ALL paths work if you have diacritics (or better yet - non-latin chars)…
1 Like
A big thanks to Bill for stepping out and doing the job nobody wanted !
3 Likes
No, it takes a lot of time. Starting the app and validating it launches is no test, you need to use it, preferably for real-life use cases. Most of the bugs we have happen when stressing the RAM usage on tight configs, or with weird interactions between features when the editing history is growing. Forget real use in a VM (perf and color management ??? OpenCL divers ???).
Give it to my wife, she will find a way to make it crash. But she may also loose an hour of work in the process.
3 Likes
And we can’t afford to have our wives loose hours of work…
1 Like
then you find a bug and have to figure out how Windows works.
After sorting out the non bug bugs due to misuse misunderstanding ignorance or incomplete or inaccurate explanation etc etc… You guys do a great job
Side question: I know how to compile the development versions from Github, but how do I compile the stable releases?
use checkout to select version tag…not sure of the exact syntax but its on the main github page if you scroll down
Like half of the users on Facebook/Reddit etc? 
I realize that not everyone frequents Pixls.us, but it always boggles my mind how many people just cry “Bug!” when the answer was in the manual all along.
Look here. The tag name is listed on the left hand side. For example, for version 3.6, you should git checkout release-3.6.0 before building
Thanks for the effort.
I will try to help testing development releases in windows.
I have recently installed 3.7 version from a post here in pixls.
I have install it in other directory and use a different config dir from mainstream 3.6 version.
But I had not realized the potential problem of xmp sidecars… I will disable xmp writing in the 3.7 version.
But having a more easy install process (of dev releases) that takes that into account would be great.
I will try to help as much as I can, but I not confident enough to offer help in the administrative process.
But having a list of new changes and things to test from release to realease would be great for common users, no doubt.
Issue tracking and dev speak in github is not easily undertandable for common users (i have some program experience, but not used to nowadays projecto management tools).
Thank you for the effort and for taking windows users into account.
If you use a different directory for storing the photos you want to process in 3.7, you won’t have a sidecar problem.