KStars v3.5.0 Release Date?

Mon Nov 9 22:51:05 GMT 2020

I looked into the issue with executeMeridianFlip unchecking itself, and,
yes, it was in the polar align code.
I have submitted an MR, see
https://invent.kde.org/education/kstars/-/merge_requests/126 (Jasem, please
double check for me that this makes sense to you.)
As I say in the MR comment, but I feel it's important enough to repeat here:

*Honestly, this isn't a 100% fix. I believe it is a fix worth doing, as it
will solve the problem much of the time (as long as the user explicitly
exits the polar align).*

*However, if the user simply leaves polar align without clicking 'done'
(e.g. by just clicking on the Solution Results sub-tab) then his/her flags
won't be restored. Polar align should not be messing with the user's
Options--there should be another way of preventing the MF. That said, it's
too close to the release for me (with limited knowledge of align) to
re-wire the thing. I'd recommend that someone more familiar with align
refactors/re-organizes at some point so that Options::executeMeridianFlip()
is never changed inside of polar align.*

Hy

PS I did find an odd issue while doing this.

Stderr or stdout spewed hundreds of lines like:

Error: seeking, reading, or closing file
/tmp/internalSextractorSolver_21.solved: Invalid argument
Error: seeking, reading, or closing file
/tmp/internalSextractorSolver_21.solved: Invalid argument
Error: seeking, reading, or closing file
/tmp/internalSextractorSolver_21.solved: Invalid argument
...

when I tried to polar align with the simulator (I was using profile:
"Internal SEP/Internal Solver/4-SmallScaleSolving"). Does this ring a bell?

On Mon, Nov 9, 2020 at 1:27 PM Hy Murveit <murveit at gmail.com> wrote:

> I would say it's been pretty solid for me the last few days. I've tried to
> test every night when possible. Good work folks!
>
> Two things I wanted to bring up:
>
> #1. There was one thing I was looking into, going to try again right now.
> I think this would be a good thing to fix for 3.5.0 if I can find the fix
> and it is straightforward.
> Occasionally, though I try to set it so that it's always enabled, the
> Meridian Flip Checkbox sometimes
> mysteriously is not set when I start Ekos.
>
> This has led to missed flips & a few tripod collisions for me over the
> past year (though now I mostly always
> remember to check if it's on). A friend recently privately reported to me
> that the same thing happened to him last week.
> I suspect the polar alignment code is to blame, (I noticed it unchecks and
> later re-checks the option) but not sure yet.
>
> #2. I'm not thrilled that Align's star-extraction profiles default to a
> profile labeled "*Default profile. Generic and not optimized for any
> specific purpose*".
> I would rather it defaulted to one of the profiles optimized for
> Align--e.g. Small Scale Solving. Or, perhaps some middle
> ground between Small Scale and Large Scale. What do you think?
>
> Hy
>
> On Mon, Nov 9, 2020 at 1:04 PM Jasem Mutlaq <mutlaqja at ikarustech.com>
> wrote:
>
>> 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/20201109/fcbf5fe4/attachment-0001.htm>