KStars Developers Hangout #1

[Hy Murveit]

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/20200608/95fbb6c3/attachment.htm>