I have been working on Snap packagers for over a year without much success. Using snap packages, we can release sandboxed INDI & KStars releases that are completely separate. If something doesn't work then you can simply roll-back to whatever version that works. Furthermore, user can select from "Stable" and "Development" channel in the snap store and switch between them at will. That's what is nice about sandboxed applications.

The problem is that it is quite complex. I tried to package everything in one snap (KStars + INDI), but I guess that's not a very good idea. We could separate them into two snaps, while having KStars snap depend on the INDI one. If someone is willing to invest time to work on this, it is going to help immensely with the project.

I already started and the snap packaging files for KStars are here: github.com/KDE/kstars/tree/master/packaging/linux/snap

On paper it sounds like a good plan, however if it's going to add more complexity and will take more effort/time to work on, then maybe we need to look into a different option? Just thinking out loud there.

For example, do we have a page somewhere where the bugs are being tracked properly? Something clear to read and understand.
Let's say, there is bug X on driver B, reported by user A. Bug get fixed, user A must check that it's in fact corrected. And if OK, this driver update goes live.

Github issues page is used to track driver bugs.

However, this suggestion is about PPA vs. Snap package. With PPA, you don't have much control. Whatever compiles there you use. This is of course is only applicable to Linux. With snap packages, you can rollback in case something breaks.

I see OK, found the following link for anyone trying to understand the difference between the two
www.linuxandubuntu.com/home/snap-vs-deb-package

Well If it's as good as they say it is, then I think we should invest some time into this after all.
I can setup a Linux server anytime for testing this snap thing.

I'm not convinced by that snap thing. I mean, that's presented as a gold solution for end-users, but in the end that's not bringing that much added value in terms of dependency control. It's not even entirely clear what happens on non-supported platforms. The model seems to transfer pressure from the end-users on the developers by creating a sort of application ecosystem where all situations are taken into account, without providing any additional means to support the integration of the components providing those applications.
-Eric