KStars v3.5.0 Release Date?

Tue Nov 10 13:03:14 GMT 2020

OK, I did a quick check on my RPi4 with Parallel Algorithm set to „Auto“ - and it works super fast! But since it is daytime, I can only test the „Load and Slew“ option. So maybe the WCS info in the file gave hints that are not present for normal capture and slew or sync.

I need to check it under real conditions, which might be tricky due to the fog hanging around here…

Wolfgang
> Am 10.11.2020 um 11:16 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
> 
> Alright, let's look at this:
> 
> 1. Parallel algorithm: This is related to SOLVER, not image partitioning. It should work fine on Rpi4 and the checks are more reliable now as Robert worked on that.
> 2. WCS Polar Align: Can this be reproduced with simulators?
> 
> --
> Best Regards,
> Jasem Mutlaq
> 
> 
> 
> On Tue, Nov 10, 2020 at 10:48 AM Wolfgang Reissenberger <sterne-jaeger at openfuture.de <mailto:sterne-jaeger at openfuture.de>> wrote:
> It wasn’t that bad. The problem was that KStars went to 100% CPU usage and died (or I killed it, do not exactly remember). I’ll try to reproduce it...
> 
>> Am 10.11.2020 um 08:45 schrieb Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>>:
>> 
>> OK, well I believe it was fixed a week ago, so if you can still recreate it, you should report it. 
>> It should be fixed before release if it is still freezing the Pi.
>> 
>> Hy
>> 
>> On Mon, Nov 9, 2020 at 11:42 PM Wolfgang Reissenberger <sterne-jaeger at openfuture.de <mailto:sterne-jaeger at openfuture.de>> wrote:
>> OK, I have to check it. The problem occurred only a few days ago and I think I’m always on bleeding edge...
>> 
>>> Am 10.11.2020 um 08:38 schrieb Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>>:
>>> 
>>> Wolfgang: I believe Rob and/or Jasem fixed the issue with parallel algorithm bringing down the RPi4 a while back.
>>> I have the solver on auto parallelism and load all indexes in memory, and it seems to work fine (and in parallel).
>>> Similarly, for star extraction, Jasem implemented a threaded extraction that also automatically determines how many threads to use and seems fine on the RPi4.
>>> 
>>> Eric: I believe these parallel options are the defaults. Hopefully users won't need to configure things like this.
>>> For star detection, I don't believe you can turn it off.
>>> For star detection Jasem split the frame before detection (into at most num-threads parts--4 for the RPi4).
>>> For align, I'm not sure how Rob divided things.
>>> 
>>> Hy
>>> 
>>> On Mon, Nov 9, 2020 at 11:07 PM Wolfgang Reissenberger <sterne-jaeger at openfuture.de <mailto:sterne-jaeger at openfuture.de>> wrote:
>>> Hi all,
>>> I think we are close to finishing the release. I personally would opt to wait for another week and keep an eye stability.
>>> 
>>> Maybe we should take another look if the default settings in the StellarSolver profiles work a) for typical camera/scope combinations and b) for all platforms.
>>> 
>>> For example with my RPi, I needed to change the Parallel Algorithm to „None“ because parallelity brought KStars down. Is the default setting „None“ and I changed it somewhen? With all the new parameters I would prefer having a robust setup and leave it to the user to optimize speed.
>>> 
>>> @Jasem: please take a closer look to MR!122, since it fixed 4(!) regressions I introduced with my capture counting fix MR!114. Hopefully now we have at least a proper coverage with automated tests...
>>> 
>>> Wolfgang
>>> 
>>>> Am 09.11.2020 um 22:04 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com <mailto:mutlaqja at ikarustech.com>>:
>>>> 
>>>> Hello Folks,
>>>> 
>>>> So back to this topic, any major blockers to the KStars 3.5.0 release now?
>>>> 
>>>> 1. Remote Solver should be fixed now.
>>>> 2. StellarSolver Profiles are more optimized now.
>>>> 3. Handbook not updated yet, but we can probably work on this shortly.
>>>> 4. Couple of pending MRs to take care of.
>>>> 
>>>> How about Friday the 13th?
>>>> 
>>>> --
>>>> Best Regards,
>>>> Jasem Mutlaq
>>>> 
>>>> 
>>>> 
>>>> On Thu, Nov 5, 2020 at 3:41 AM Robert Lancaster <rlancaste at gmail.com <mailto:rlancaste at gmail.com>> wrote:
>>>> Hi Eric,
>>>> 
>>>> Ok so then we would be changing the way we do version numbering with this, right?
>>>> I believe now we typically add features in each new iteration 3.4.1, 3.4.2, etc etc
>>>> and when it is really big like StellarSolver, then we make it a big release like 3.5.0
>>>> 
>>>> With this new paradigm, we wouldn’t put new features into the master of the main 3.5 branch
>>>> But instead we would work on a new 3.6 branch, and then bug fixes would go into the 3.5 branch
>>>> to make each new minor release, like 3.5.1, 3.5.2 etc.
>>>> 
>>>> Do I have this correct?
>>>> 
>>>> If this is right, then it would be longer before users see new features in the main branch, but the 
>>>> tradeoff is that the main branch would have a LOT more stability.  I see this as a big positive.
>>>> 
>>>> Thanks,
>>>> 
>>>> Rob
>>>> 
>>>> > On Nov 4, 2020, at 5:54 PM, Eric Dejouhanet <eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com>> wrote:
>>>> > 
>>>> > Hello Hy,
>>>> > 
>>>> > Version 3.5.0 is only the beginning of the 3.5.x series, with more
>>>> > bugfixes on each iteration (and possibly, only bugfixes).
>>>> > So I have no problem leaving unresolved issues in 3.5.0.
>>>> > 
>>>> > For instance, the Focus module now has a slight and unforeseeable
>>>> > delay after the capture completes.
>>>> > The UI reflects the end of the capture only, not the end of the detection.
>>>> > This makes the UI Focus test quite difficult to tweak, as running an
>>>> > average of the HFR over multiple frames now has an unknown duration.
>>>> > Right now, the test is trying to click the capture button too soon 2
>>>> > out of 10 attempts.
>>>> > But this won't block 3.5 in my opinion (and now that I understood the
>>>> > problem, I won't work on it immediately).
>>>> > 
>>>> > In terms of reporting problems, the official way is stil bugs.kde.org <http://bugs.kde.org/>,
>>>> > but there's quite a cleanup/followup to do there.
>>>> > I'd say we can use issues in invent.kde.org <http://invent.kde.org/> to discuss planned
>>>> > development around a forum/bugzilla issue or invent proposal (like
>>>> > agile stories).
>>>> > There are milestones associated with several issues (although I think
>>>> > they should be reviewed and postponed).
>>>> > And we can certainly write a punchlist: check the board at
>>>> > https://invent.kde.org/education/kstars/-/milestones/3 <https://invent.kde.org/education/kstars/-/milestones/3>
>>>> > 
>>>> > Le mer. 4 nov. 2020 à 22:38, Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> a écrit :
>>>> >> 
>>>> >> Eric,
>>>> >> 
>>>> >> I would add to your list:
>>>> >> 
>>>> >> - KStars Handbook (review update sections to reflect 3.5.0) and finally (perhaps manually if necessary) put the latest handbook online.
>>>> >> 
>>>> >> - Review the extraction settings. I spent a bit of time looking at the default HFR settings, and based on some experimentation (truth be told, with a limited amount of data) adjust things a little differently than my first guess (which was basically focus' settings).
>>>> >> Rob: My intuition is that I should adjust the default StellarSolver star-extraction settings for Focus and Guide as well in stellarsolverprofile.cpp. I don't know whether you've already verified them, and want to release them as they are, or whether they are a first shot and you'd welcome adjustment?
>>>> >> 
>>>> >> Also, Eric, I suppose I should be adding these things here: https://invent.kde.org/education/kstars/-/issues <https://invent.kde.org/education/kstars/-/issues>
>>>> >> Is that right? Sorry about that--ok, after this thread ;) But seriously, your email is a good summary, and from that link
>>>> >> it doesn't seem as easy to see which are "must do by 3.5.0" and which are "nice to have someday".
>>>> >> A 3.5.0 punchlist would be a nice thing to have.
>>>> >> 
>>>> >> Hy
>>>> >> 
>>>> >> On Wed, Nov 4, 2020 at 12:58 PM Eric Dejouhanet <eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com>> wrote:
>>>> >>> 
>>>> >>> Hello,
>>>> >>> 
>>>> >>> Where do we stand now in terms of bugfixing towards 3.5.0?
>>>> >>> 
>>>> >>> - StellarSolver has all features in, and 1.5 is finally out at Jasem's PPA.
>>>> >>> - However Gitlab CI still complains about that lib package (see
>>>> >>> https://invent.kde.org/education/kstars/-/jobs/75941 <https://invent.kde.org/education/kstars/-/jobs/75941>)
>>>> >>> - Unitary tests are being fixed progressively, mount tests are down to
>>>> >>> ~20 minutes (yeees!)
>>>> >>> - From my tests, the remote Astrometry INDI driver is not usable
>>>> >>> anymore from Ekos.
>>>> >>> - The issue raised with flat frames is confirmed fixed (at least by me).
>>>> >>> - Meridian flip is OK (but I had not enough time to test TWO flips in a row).
>>>> >>> - Memory leaks are still being researched in Ekos.
>>>> >>> - There is an issue when duplicating an entry in a scheduler job,
>>>> >>> where the sequence associated is copied from the next job.
>>>> >>> 
>>>> >>> Could we get a 3.6 branch where we will merge development of new features?
>>>> >>> And master for bugfixing 3.5.x until we merge 3.6 new features in?
>>>> >>> (we'd still have to port bugfixes from master to 3.6)
>>>> >>> I don't think the opposite, master for 3.6 and a separate living
>>>> >>> 3.5.x, is doable in the current configuration (build, ppas, MRs...).
>>>> >>> 
>>>> >>> --
>>>> >>> -- eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com> - https://astronomy.dejouha.net <https://astronomy.dejouha.net/>
>>>> > 
>>>> > 
>>>> > 
>>>> > -- 
>>>> > -- eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com> - https://astronomy.dejouha.net <https://astronomy.dejouha.net/>
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201110/46335fa2/attachment.htm>