KStars Developers Hangout #1

[Jasem Mutlaq]

Great ideas folks!

I think another important thing is what happens _after_ these meetings are
concluded? We have had a meeting before and no tangible outcomes were
realized. Maybe the meeting itself should include some  "action points"
that are tasked to a person/group and then followed up with?

--
Best Regards,
Jasem Mutlaq



On Mon, Jun 8, 2020 at 10:30 PM Wolfgang Reissenberger <
sterne-jaeger at openfuture.de> wrote:

> 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>
> wrote:
>
>> There's a discussion at
>> 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 to track problems for now.
>>
>> --
>> -Eric
>>
>> mailto: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/20200609/4fb54d4c/attachment.htm>