KStars v3.5.0 Release Date?

Tue Nov 10 10:16:35 GMT 2020

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> 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>:
>
> 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> 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>:
>>
>> 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> 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>:
>>>
>>> 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>
>>> 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> 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
>>>> ,
>>>> > but there's quite a cleanup/followup to do there.
>>>> > I'd say we can use issues in 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
>>>> >
>>>> > Le mer. 4 nov. 2020 à 22:38, Hy Murveit <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
>>>> >> 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> 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)
>>>> >>> - 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 - https://astronomy.dejouha.net
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > -- eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201110/4fef4722/attachment.htm>