On today’s TrueNAS Tech Talk, Kris digs into a major feature in the upcoming TrueNAS 26.04 “Halfmoon” release - Spotlight search support for MacOS. Find out how the new “truesearch” service will work to index and catalog your files to give lightning-fast search results, in a common back-end DB, so that additional search protocols can extend the functionality in the future. Chris and Kris will also tackle a pack of viewer questions - and probably sign themselves up for a bunch more Feature Requests as a result!
The link is to a Feature Request which is one year old, has (holds!) 43 votes, but has yet to be processed.
There must be a set time line for requests to be reviewed, be that “x months from original post” or “general review every x months”, and then requests are accepted or declined. No, or not much, explanation needed.
But release the votes!
If the outcome has to be “still need thinking about”, release votes anyway, or allocate more votes. The current situation just results in paralysis: Requests pile up, and those interested are out of votes anyway so no input is given. (This other link has 100 votes and is 10 months old. No decision.)
Maybe offtopic but recently I was thoroughly searching the internet for the ultimate Windows search tool and maybe this will help some people struggling with the same problem.
First I would like to give honorary mention to Everything which is great for free tool but its mainly good for filenames and metadata.
The true ultimate tool is FileLocator Pro. Its got free Lite version but the Pro version can do basically everything and I couldnt find any other tool that could do as much.
It can of course search filenames and metadata, but also any content on PC. It can search in emails for both Outlook and Thunderbird for attachments and their content. If PDF contains text thats easy, but it can even do OCR and search in imaged based PDF (for example scanned documents). It offers preview in form of text and as pdf viewer. And you can create index so searching is blazing fast. Only creating that index takes long.
Well, the search indexing reminded me of this because I spent a long time searching for the best tool.
This is the kind of constructive criticism and feedback I can make take back to the engineering team to make actionable.
Kris and I have tried to explain a bit about the decision process and how it’s way more complex than it looks on the surface to implement, test, merge something - and while it’s certainly possible to put an “accepted” or “rejected” on a request in a given time frame, it risks just punting the issue and having the same problem of “it was accepted N months ago, why isn’t it in the product now?” if the feature turns out to be more nuanced than it looks.
It’s not to say we can’t or won’t improve the process (especially around the communication) but to dismiss the entirety of feature requests as a joke is a bit much, IMO.
But it should not be too much to ask some kind of reaction to feature requests with dozens of votes. A little “hey thanks for the request we’re looking into it” would go a long way to show that it’s not getting ignored…
I don’t think they rise even to that level–the situation certainly isn’t funny.
If you want the community to take them seriously, then you need to take them seriously, and be seen to be taking them seriously. That means you engage with them, particularly when they’ve gotten dozens of votes. You may recall that, when feature requests were done on Jira, ten votes were the threshold for you all to do something, even if that “something” was “mark it as accepted, and then still let it languish for years” (see, e.g., the file manager that was requested 8+ years ago). At least you acknowledged it.
So now feature requests are on the forum–as they’d been in the past. Probably a good thing, generally speaking, for the sake of everyone’s visibility. But now it’s front and center that you can’t be bothered to address most of them. And I’m pretty sure I’m not the only one who’s concluded from that that you just don’t care about them.
Don’t tell me much you care, and how much you value community input–I don’t want to hear it. Act on them. Hell, even engaging with them would be a good start.
I’m putting my name out there (similar to the “I’ll fork it myself” comment) - I’m going to personally take ownership of the communication chain here. I’ll start combing through the FR’s, and while I’m not making the call of what makes the cut and when, I can certainly offer some insight and my own takes on the likely outcomes should I bring a given feature up.
Indeed, managing users’ expertectations will be another issue, but this stage would already be a huge improvement over “this has been open for 10 months and no word about it” or, even worse, “hmm, interesting but I’m out of votes”. I cannot understate how much damage the latter does…
Since TrueNAS is a on a 6 month schedule, maybe the team could have a meeting twice a year, at an appropriate moment to define the features which could go on the next or the next next release, and review pending requests.
Again, the review process can be short. But “sorry, can’t/won’t do it” is better than “left open indefinitely”.
That’s actually what happens now - features are scoped out for the following major release and ideally locked in (so that no one scope-creeps new things in and sidetracks prior work) so like I said it’s been the responses that have been lacking.
I should clarify that a new version is scoped about a year before it gets to release… it requires development, test, then BETA, RC.1 and RELEASE. So, even if an idea is great and accepted easily, it’s probably going to be a 15 month process before it’s in released software.
We do review the Feature Requests and their votes. However, there are several other criteria:
Does it help our customers?
Is it related to other software changes being made?
Is it easy or hard to change without breaking something else?
Is the developer of this area already slammed?
I just did a count… we’ve accepted 23 Feature Requests in the last 14 months. Some of them are pretty large.
We also invite developers to join us via Github (edit) and contribute. We always need more (good) developers…and that would help increase the rate. Developers can have their features in more quickly.
Fine. “Accepted: Planned/Considered for fish xx.xx” is a positive outcome even if further away than the requester would have hoped.
The request about requests here is that requests are timely closed: Accepted or rejected, but NOT left in limbo indefinitely.
There are far more than 23 threads in the Feature Request section. Please close at your earliest convenience all those requests that have been scoped out and reviewed.
That should be caught in the “periodic review” task of the background service, where it would consider the files that it can get new understanding on as “these need a re-check” - but we’ll see if we can test this out.
I’ll have to see what knobs we’ll be exposing in the UI/service configuration but since the DB will be residing on a ZFS dataset, you should be able to force everything to be caught by setting special_small_blocks >= recordsize of the dataset where it’s stored, thereby telling ZFS “all blocks in this dataset are special”
One more question: is TrueNAS 26.04 going to have ZFS 2.4, given that the RC1 of ZFS2.4 is out?
The reason I’m asking:
There’s a key issue being fixed, which would allow a “fusion pool” to be actually be meaningfully created, with ZIL, small files, metadata all living on a RAIDZ2 SSD-based special vdev and large files ending up on spinning disks, also in a RAIDZ2 configuration.
(Things will become really fun, once AnyRAID can do RAIDZ2, but that’s further into the future…)
Of course, that would require a minor change in the UI to allow for different VDEV configurations other than mirror…
A paying customer needs the feature or something similar
I agree we should reject features we don’t think are feasible, but others are in limbo waiting for these changes. It would be good if the forum software could sort it better…
We’ll review the process… we’d prefer it to be improved as well.
I guess I asked slightly wrong: What I mean, will the nightlies run with 2.4RC1/RC2, etc. or will the nightlies switch to 2.4 once it’s officially released and pushed into the official debian repositories?
The special vdev changes (i.e. being able to use RAIDZ2 instead of just mirrors) is kind of what I’m looking for to test out.
We don’t wait for Debian, but we do schedule for our convenience. We are testing it internally and its likely to be in by ALPHA time. Guess would be end of the year…
