<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi all,<div class="">I think we are close to finishing the release. I personally would opt to wait for another week and keep an eye stability.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">@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...</div><div class=""><br class=""></div><div class="">Wolfgang</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 09.11.2020 um 22:04 schrieb Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" class="">mutlaqja@ikarustech.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello Folks,<div class=""><br class=""></div><div class="">So back to this topic, any major blockers to the KStars 3.5.0 release now?</div><div class=""><br class=""></div><div class="">1. Remote Solver should be fixed now.</div><div class="">2. StellarSolver Profiles are more optimized now.</div><div class="">3. Handbook not updated yet, but we can probably work on this shortly.</div><div class="">4. Couple of pending MRs to take care of.</div><div class=""><br class=""></div><div class="">How about Friday the 13th?</div><div class=""><br class=""></div><div class=""><div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">--</div><div class="">Best Regards,<br class="">Jasem Mutlaq<br class=""></div><div class=""><br class=""></div></div></div></div></div></div><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 5, 2020 at 3:41 AM Robert Lancaster <<a href="mailto:rlancaste@gmail.com" class="">rlancaste@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eric,<br class="">
<br class="">
Ok so then we would be changing the way we do version numbering with this, right?<br class="">
I believe now we typically add features in each new iteration 3.4.1, 3.4.2, etc etc<br class="">
and when it is really big like StellarSolver, then we make it a big release like 3.5.0<br class="">
<br class="">
With this new paradigm, we wouldn’t put new features into the master of the main 3.5 branch<br class="">
But instead we would work on a new 3.6 branch, and then bug fixes would go into the 3.5 branch<br class="">
to make each new minor release, like 3.5.1, 3.5.2 etc.<br class="">
<br class="">
Do I have this correct?<br class="">
<br class="">
If this is right, then it would be longer before users see new features in the main branch, but the <br class="">
tradeoff is that the main branch would have a LOT more stability. I see this as a big positive.<br class="">
<br class="">
Thanks,<br class="">
<br class="">
Rob<br class="">
<br class="">
> On Nov 4, 2020, at 5:54 PM, Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a>> wrote:<br class="">
> <br class="">
> Hello Hy,<br class="">
> <br class="">
> Version 3.5.0 is only the beginning of the 3.5.x series, with more<br class="">
> bugfixes on each iteration (and possibly, only bugfixes).<br class="">
> So I have no problem leaving unresolved issues in 3.5.0.<br class="">
> <br class="">
> For instance, the Focus module now has a slight and unforeseeable<br class="">
> delay after the capture completes.<br class="">
> The UI reflects the end of the capture only, not the end of the detection.<br class="">
> This makes the UI Focus test quite difficult to tweak, as running an<br class="">
> average of the HFR over multiple frames now has an unknown duration.<br class="">
> Right now, the test is trying to click the capture button too soon 2<br class="">
> out of 10 attempts.<br class="">
> But this won't block 3.5 in my opinion (and now that I understood the<br class="">
> problem, I won't work on it immediately).<br class="">
> <br class="">
> In terms of reporting problems, the official way is stil <a href="http://bugs.kde.org/" rel="noreferrer" target="_blank" class="">bugs.kde.org</a>,<br class="">
> but there's quite a cleanup/followup to do there.<br class="">
> I'd say we can use issues in <a href="http://invent.kde.org/" rel="noreferrer" target="_blank" class="">invent.kde.org</a> to discuss planned<br class="">
> development around a forum/bugzilla issue or invent proposal (like<br class="">
> agile stories).<br class="">
> There are milestones associated with several issues (although I think<br class="">
> they should be reviewed and postponed).<br class="">
> And we can certainly write a punchlist: check the board at<br class="">
> <a href="https://invent.kde.org/education/kstars/-/milestones/3" rel="noreferrer" target="_blank" class="">https://invent.kde.org/education/kstars/-/milestones/3</a><br class="">
> <br class="">
> Le mer. 4 nov. 2020 à 22:38, Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank" class="">murveit@gmail.com</a>> a écrit :<br class="">
>> <br class="">
>> Eric,<br class="">
>> <br class="">
>> I would add to your list:<br class="">
>> <br class="">
>> - KStars Handbook (review update sections to reflect 3.5.0) and finally (perhaps manually if necessary) put the latest handbook online.<br class="">
>> <br class="">
>> - 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).<br class="">
>> 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?<br class="">
>> <br class="">
>> Also, Eric, I suppose I should be adding these things here: <a href="https://invent.kde.org/education/kstars/-/issues" rel="noreferrer" target="_blank" class="">https://invent.kde.org/education/kstars/-/issues</a><br class="">
>> Is that right? Sorry about that--ok, after this thread ;) But seriously, your email is a good summary, and from that link<br class="">
>> it doesn't seem as easy to see which are "must do by 3.5.0" and which are "nice to have someday".<br class="">
>> A 3.5.0 punchlist would be a nice thing to have.<br class="">
>> <br class="">
>> Hy<br class="">
>> <br class="">
>> On Wed, Nov 4, 2020 at 12:58 PM Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a>> wrote:<br class="">
>>> <br class="">
>>> Hello,<br class="">
>>> <br class="">
>>> Where do we stand now in terms of bugfixing towards 3.5.0?<br class="">
>>> <br class="">
>>> - StellarSolver has all features in, and 1.5 is finally out at Jasem's PPA.<br class="">
>>> - However Gitlab CI still complains about that lib package (see<br class="">
>>> <a href="https://invent.kde.org/education/kstars/-/jobs/75941" rel="noreferrer" target="_blank" class="">https://invent.kde.org/education/kstars/-/jobs/75941</a>)<br class="">
>>> - Unitary tests are being fixed progressively, mount tests are down to<br class="">
>>> ~20 minutes (yeees!)<br class="">
>>> - From my tests, the remote Astrometry INDI driver is not usable<br class="">
>>> anymore from Ekos.<br class="">
>>> - The issue raised with flat frames is confirmed fixed (at least by me).<br class="">
>>> - Meridian flip is OK (but I had not enough time to test TWO flips in a row).<br class="">
>>> - Memory leaks are still being researched in Ekos.<br class="">
>>> - There is an issue when duplicating an entry in a scheduler job,<br class="">
>>> where the sequence associated is copied from the next job.<br class="">
>>> <br class="">
>>> Could we get a 3.6 branch where we will merge development of new features?<br class="">
>>> And master for bugfixing 3.5.x until we merge 3.6 new features in?<br class="">
>>> (we'd still have to port bugfixes from master to 3.6)<br class="">
>>> I don't think the opposite, master for 3.6 and a separate living<br class="">
>>> 3.5.x, is doable in the current configuration (build, ppas, MRs...).<br class="">
>>> <br class="">
>>> --<br class="">
>>> -- <a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a> - <a href="https://astronomy.dejouha.net/" rel="noreferrer" target="_blank" class="">https://astronomy.dejouha.net</a><br class="">
> <br class="">
> <br class="">
> <br class="">
> -- <br class="">
> -- <a href="mailto:eric.dejouhanet@gmail.com" target="_blank" class="">eric.dejouhanet@gmail.com</a> - <a href="https://astronomy.dejouha.net/" rel="noreferrer" target="_blank" class="">https://astronomy.dejouha.net</a><br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>