
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Dear Hy,<div class="">Point 2 from your proposal hits exactly what I would like to discuss, but what about splitting it into two parts:</div><div class="">- 2.1 Code Style and Documentation</div><div class="">- 2.2 Code Review Process</div><div class=""><br class=""></div><div class="">Beyond that, I would like to propose a third topic:</div><div class=""><br class=""></div><div class="">3) EKOS Layer Separation</div><div class=""><br class=""></div><div class="">Motivation: Currently, we have huge C++ classes, more or less one per module. They all contain several levels of abstractions: low level INDI data processing, UI control, complex state machines, workflow control. On top of that, handling INDI data from the same device is meanwhile spread over several modules. The best example for this is mount slewing handling is interpreted in Align, Capture, Scheduler and Guide. As a result, these classes are very difficult to maintain.</div><div class=""><br class=""></div><div class="">Proposal: We introduce a device layer, one for each astronomical device, which handles the INDI data processing, has its one elaborated state machine. Above this device layer, we have a workflow layer that interacts with the devices by listening to state changes and accessing the devices with device specific APIs.</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Wolfgang</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 08.06.2020 um 21:02 schrieb Hy Murveit <<a href="mailto:murveit@gmail.com" class="">murveit@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Let's say that the deadline for topic proposal is this Friday, June 12, and on Sat June 13 I'll send out an email putting the proposals together for a vote.<br class=""></div><div class=""></div></div><div class=""><br class=""></div><div class="">Eric: I wasn't sure. Was your previous email a topic proposal?</div><div class=""><br class=""></div>Here are two topic suggestions I'm putting forward for our proposed call.<div class=""><div class=""><br class=""></div><div class="">1) KStars/Indi/KDE...Project organization and how it fits together.</div><div class=""><br class=""></div><div class="">Can someone (Jasem?) please explain the structure of the "organization" of this project.</div><div class="">That is, how do we fit inside the larger picture.</div><div class="">How do things work. E.g. Kstars was moved from phabricator to gitlab. </div><div class="">who decided? how are they related to us? Do they pay for this? How does this money work?</div><div class="">Formally, what role does Jasem play? Does he have a formal title and responsibilities?</div><div class="">What are they?</div><div class="">Are Indi and KStars different things? How are they related?</div><div class="">Also, related, what is the infrastructure KStars uses for code (gitlab), compiling and releasing, forums, ... how is that organized?</div><div class="">Who are the people that worry about internationalization, builds, tests, ... how does that work?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">2) Coding health/maintenance.</div><div class="">I think we might formalize somewhere code style, in the larger sense.</div><div class="">- Does all this (below) already exist somewhere?</div><div class="">- Where should this meta-documentation (how KStars code is written) exist?</div><div class=""></div><div class="">- how code should be documented going forward, even if it isn't that way right now. Specifically, for classes, headers, .cpp files etc. Pointing to examples of good doc.</div><div class="">- how tests should be written, even if they aren't that way right now.</div><div class="">- low level doc: how should code be formatted.<br class=""></div><div class="">- how code reviews should work (Editorial comment: I believe we should be a little picky-er in our code reviews).</div><div class=""></div><div class="">- Who allows merge requests? For instance, is the answer, only Jasem can approve a MR? (Editorial comment: I have no issue with that, in fact I support it, but I think we should spell it out). </div><div class="">- Should we have a process where every MR gets reviewed (e.g. Jasem submits code without review. Can anyone else? Should Jasem's code go through review? Perhaps there should be a mechanism/policy where Jasem submits code, but someone needs to review it later, so that little bug fixes don't get bogged down, but submissions do get seen by more than one pair of eyes. Presumably no-one else can do that.)</div><div class="">- How can we remove dead code? There's plenty of it in KStars.</div><div class="">- Is there a process for removing functionality that is in the way of code health--e.g. say one wanted to totally refactor capture, but complications related probably lightly-used feature X prevent this.</div></div><div class="">- We wouldn't end a call with a finished process, we'd discuss some issues and then assign someone to write a document which would then get comments, ultimately get approved, and live somewhere with changes code-reviewed like anything else.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 7, 2020 at 8:45 AM Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" class="">eric.dejouhanet@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">There's a discussion at <br class="">

<a href="https://gitlab.com/gitlab-org/gitlab-foss/-/issues/27782" rel="noreferrer" target="_blank" class="">https://gitlab.com/gitlab-org/gitlab-foss/-/issues/27782</a> about having a <br class="">

vote system for GitLab (they also talk about feature gates there).<br class="">

<br class="">

Let us formalize the features found in the forum into GitLab issues, and <br class="">

have users vote for them with reaction badges. This way we may consider <br class="">

multiple implementation facets and architecture impacts before deliving <br class="">

into code?<br class="">

<br class="">

I suppose this should not prevent the development of features no one <br class="">

wants to have, but we would get an agreement on how things are supposed <br class="">

to work for some new features.<br class="">

<br class="">

We would keep <a href="http://bugs.kde.org/" rel="noreferrer" target="_blank" class="">bugs.kde.org</a> to track problems for now.<br class="">

<br class="">

-- <br class="">

-Eric<br class="">

<br class="">

mailto:<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>