KStars Developers Hangout #1

[Wolfgang Reissenberger]

Dear Hy,
Point 2 from your proposal hits exactly what I would like to discuss, but what about splitting it into two parts:
- 2.1 Code Style and Documentation
- 2.2 Code Review Process

Beyond that, I would like to propose a third topic:

3) EKOS Layer Separation

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.

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.

Cheers
Wolfgang

> Am 08.06.2020 um 21:02 schrieb Hy Murveit <murveit at gmail.com>:
> 
> 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.
> 
> Eric: I wasn't sure. Was your previous email a topic proposal?
> 
> Here are two topic suggestions I'm putting forward for our proposed call.
> 
> 1) KStars/Indi/KDE...Project organization and how it fits together.
> 
> Can someone (Jasem?) please explain the structure of the "organization" of this project.
> That is, how do we fit inside the larger picture.
> How do things work. E.g. Kstars was moved from phabricator to gitlab. 
> who decided? how are they related to us? Do they pay for this? How does this money work?
> Formally, what role does Jasem play? Does he have a formal title and responsibilities?
> What are they?
> Are Indi and KStars different things? How are they related?
> Also, related, what is the infrastructure KStars uses for code (gitlab), compiling and releasing, forums, ... how is that organized?
> Who are the people that worry about internationalization, builds, tests, ... how does that work?
> 
> 
> 2) Coding health/maintenance.
> I think we might formalize somewhere code style, in the larger sense.
> - Does all this (below) already exist somewhere?
> - Where should this meta-documentation (how KStars code is written) exist?
> - 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.
> - how tests should be written, even if they aren't that way right now.
> - low level doc: how should code be formatted.
> - how code reviews should work (Editorial comment: I believe we should be a little picky-er in our code reviews).
> - 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). 
> - 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.)
> - How can we remove dead code? There's plenty of it in KStars.
> - 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.
> - 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.
> 
> On Sun, Jun 7, 2020 at 8:45 AM Eric Dejouhanet <eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com>> wrote:
> There's a discussion at 
> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/27782 <https://gitlab.com/gitlab-org/gitlab-foss/-/issues/27782> about having a 
> vote system for GitLab (they also talk about feature gates there).
> 
> Let us formalize the features found in the forum into GitLab issues, and 
> have users vote for them with reaction badges. This way we may consider 
> multiple implementation facets and architecture impacts before deliving 
> into code?
> 
> I suppose this should not prevent the development of features no one 
> wants to have, but we would get an agreement on how things are supposed 
> to work for some new features.
> 
> We would keep bugs.kde.org <http://bugs.kde.org/> to track problems for now.
> 
> -- 
> -Eric
> 
> mailto: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/20200608/fea53b32/attachment.htm>