Extras usb-tree-view: Add version 3.8.1

App description: View USB devices in a tree-like structure.

Credit goes to @404NetworkError for his manifest here which this is based on.

[x] I have read the Contributing Guide.

Sep 29 '22 18:09 RavenMacDaddy

/verify

Sep 29 '22 18:09 RavenMacDaddy

All changes look good.

Wait for review from human collaborators.

usb-tree-view

[x] Description
[x] License
[x] Hashes
[x] Checkver

Sep 29 '22 18:09 github-actions[bot]

/verify

Sep 29 '22 18:09 RavenMacDaddy

All changes look good.

Wait for review from human collaborators.

usb-tree-view

[x] Description
[x] License
[x] Hashes
[x] Checkver

Sep 29 '22 18:09 github-actions[bot]

This will replace https://github.com/rasa/scoops/blob/master/bucket/usbtreeview.json which was first added in 2017, and has been continuously maintained since then.

In my opinion, it's better to distribute the workload by allowing apps to live in maintained buckets than to throw all apps into the main and extras bucket. What do other @ScoopInstaller/maintainers think? Should we abandon our own buckets and just add everything to extras, and maintain everything there?

Sep 30 '22 15:09 rasa

My only concern is that if a bucket isn't official, it's not discoverable for the average Scoop user.

Oct 01 '22 10:10 rashil2000

Scoop in terms of CLIs and package managers is one of the more organized alternatives.

One might argue that having everything available always, ala Chocolatey or Homebrew, is a non-issue as we're talking about manifests describing what needs to be done to manage software.

However, I think Scoop strikes a good balance and agree with @rashil2000, which is why I continue to work with the known buckets accordingly.

Oct 01 '22 13:10 RavenMacDaddy

My only concern is that if a bucket isn't official, it's not discoverable for the average Scoop user.

I'm not sure I follow. The user needs to manually add the extras bucket to search, or install apps from it, yes?

So if we throw everything in extras, how do we distribute the maintenance workload?

Perhaps we need to expand the definition of an "official" bucket. We currently have three "official" buckets outside our organization. If well known/maintained buckets were added to the official bucket list, would that alleviate the need to move everything into extras?

I know I'm sounding like a broken record, but I think it's important for Scoop's long term health and viability to have a plan on how best to build a distributed infrastructure. But if I'm a lone voice, perhaps I need to stfu.

Oct 01 '22 15:10 rasa

If well known/maintained buckets were added to the official bucket list, would that alleviate the need to move everything into extras?

I'm okay with merging rasa/scoops into ScoopInstaller (or making it an official, but non-org bucket). But since it's a (seemingly) random collection of applications, what would we categorize it as?

Oct 01 '22 17:10 rashil2000

Maintaining any bucket, whether it being additions or corrections, is always a collective contribution process.

On the subject of known buckets, one way to do it is to not necessarily categorize a particular one, though obviously if there's a clear theme, by all means.

Simply having a sub-category of known buckets named Community which contains well-maintained and extensive repositories (i.e., buckets) would mean easier additions of quality buckets for the user.

It would also mean a list of buckets that can be expanded over time as the community discovers beneficial repositories.

All of that being said, I do think it's more user-friendly to not leave them scavenging search engines and several buckets to get the software that they need.

That's why I'm still in favor of having specific, official repositories to both lean on, and maintain – together.

This also avoids the possible issue of redundancy (i.e., manifests that overlap).

Oct 01 '22 17:10 RavenMacDaddy

I am not asking that rasa/scoops be made official. I'm suggesting we consider how best to distribute the workload of app maintenance. One way would be to create official buckets for a particular category. It could be by publisher, say Sordum, or it could be by licensing, say open, free, non-free, or it could be by category, games, editors, dev tools, etc.

Or we could throw everything in main (cli) and extras (gui), but then partition the apps inside the bucket folder.

EDIT: Or we just leave things as they are...

Oct 02 '22 15:10 rasa

Something like what's first mentioned sounds reasonable to me; subdirs or specific buckets for specific publishers, depending on the size of their catalog.

It's also akin to the Nirsoft bucket that already exists in the list.

I wouldn't mind posting these ideas as a discussion (maybe a poll?) to keep things OT for the PR.

However, it does seem more fitting you do it as both the initiator of the discussion and with ownership of the ideas presented.

Oct 02 '22 18:10 RavenMacDaddy

@RavenMacDaddy Yes, I'm sorry to hijack your PR with a meta discussion of bucket organization. I've approved this PR to not let my aside sideline your effort. Once it's accepted I will delete my version in scoops.

Oct 02 '22 23:10 rasa

I like https://github.com/rasa/scoops and use it as one of my default buckets.
Bucket reorganization is a good idea for these "official" buckets, at least for "main", "extras", maybe "core", "extra-cli", "extra-gui"?
Not everything should be poured into "official" buckets if they have been in a well-maintained third-party one.

Oct 07 '22 09:10 niheaven

I know I'm sounding like a broken record, but I think it's important for Scoop's long term health and viability to have a plan on how best to build a distributed infrastructure. But if I'm a lone voice, perhaps I need to stfu.

@rasa Believe me, I stand with you for the voice of building a distributed infrastructure.

Oct 16 '22 16:10 chawyehsu

My only concern is that if a bucket isn't official, it's not discoverable for the average Scoop user.

Only official buckets are displayed in results by default, after some migrations/updates of Scoop Search. where the manifests of official bucket is clearly marked, all manifests should be displayed.