A separate repo for skycultures?

[vvasuki]

Including the skycultures with the general stellarium repo is suboptimal from the point of view of contributors who want to enrich the skycultures without daring to touch the stellarium code.

As it is, the stellarium repo is giant and formidable. Repo admins take a long time to merge pull requests - so rebasing is often required. But rebasing changes can be quite the chore for such contributors. Pushing giant changes that result can result in github timeouts. My own recent experience was to just give up, delete the fork, create a new fork and make the changes all over again.

Having a separate repo would make skyculture contribution easier and more enjoyable - ultimately leading to more of it.

[gzotti]

Just to add my impressions: We are (at least, I am) gratefully impressed if not overwhelmed by this amount of new contributors since moving repositories to Github a month ago, so please accept a delay of a few days before changes can be investigated and approved or sent into the next round of changes. This is not a commercial 24/7 enterprise, but what should be regarded as after-hour work (when amateur astronomers usually want to be outside to enjoy the real sky...) by an incredibly small but highly-motivated team with daytime obligations. In these few weeks we also had lots of initial work to set up and learn to use tools new to several of us, and released a new version with excellent new features.

The organisation and structure of Skycultures is certainly something to reconsider. On Launchpad we had a separate repository for incomplete skycultures, and overall, the increasing number of skycultures and their related increase in package size may cause problems for people totally ignorant to them (I am afraid this includes most amateur observers/DSO photographers).

Also, it is evident that the skycultures as they had been available for several years now, originally based on "Western"-only structure (constellations made out of stars, sky art, ...) need to be thoroughly extended taking other concepts into account (e.g., "dark constellations" in the Milky Way, Lunar Mansions, easier coding of borders(?), and definitely numerous issues around names and translation (e.g. labelling of an object in non-European skycultures would likely require a selection/combination of: original glyps, transliteration [into several transliteration systems depending on program language], translation, default (modern) name, and some interpretation/background information about the meaning of e.g. a mythical figure name or the importance of a certain bird or even worm depicted in the sky.) All this should of course be scientifically solid and traceable to dependable sources. See also some thoughts at https://blueprints.launchpad.net/stellarium/+spec/sky-cultures-improvement-ideas

Alexander and I have been discussing these topics several times and extended the current scheme possibly to the maximum amount possible without breaking compatibility to skycultures developed around 2009. However, we could easily need another developer (somebody deeply involved in cultural astronomy who takes a few weeks to think and write actual code) who could do the required changes. If possible, these changes or new possibilities should still keep compatibility with existing work.

[vvasuki]

I am grateful for all the work put in by the software makers and maintainers!

Regarding needed improvements to skycultures - from the perspective of vedic skyculture - I am particularly keen about:

• https://bugs.launchpad.net/stellarium/+bug/1712916 ("Skycultures: Visually distinguishing different categories of constellations")
• The ability to just partition the sky into different named patches which are not necessarily associated with any asterism (as would be in the case of a proper constellation) - viz https://bugs.launchpad.net/stellarium/+bug/1710443/comments/34 .

(As I'd offered in the past, ) I would gladly contribute towards implementing these enhancements - if I get some guidance (of the type: "this is how the code flows, you'd need to call this function to draw a longitude, and call that function to make text appear at specified coordinates"). That would give me the thrill of actually seeing the sky the way I want to see it (using stellarium).

The current input format can be extend to accommodate this - or we can go for a new JSON based format - that seems to be a mostly orthogonal topic.

[gzotti]

We are just investigating options, but may come back to your offer within days or a few weeks, thank you. Unfortunately learning the code is mostly a self-study exercise. Classes to start reading for a better understanding are src/core/modules/Constellation.(hpp|cpp) and Asterism.(hpp|cpp). But please don't rush anything into premature implementation, this task needs some specification and collection of ideas first.

[axd1967]

Including the skycultures with the general stellarium repo is suboptimal from the point of view of contributors who want to enrich the skycultures without daring to touch the stellarium code.

As it is, the stellarium repo is giant and formidable. Repo admins take a long time to merge pull requests - so rebasing is often required. But rebasing changes can be quite the chore for such contributors. Pushing giant changes that result can result in github timeouts.

@vvasuki

I'm a bit surprised about the Git performance issues

• can you give an example of such giant changes?
  -Also, did you perform the rebasing out of the github webpage (i.e. relied on GitHub doing the rebasing)

My own recent experience was to just give up, delete the fork, create a new fork and make the changes all over again.

Having a separate repo would make skyculture contribution easier and more enjoyable - ultimately leading to more of it.

IMHO extracting components could lead to complications in managing the overall project.
Git should be capable to deal with changes; contributors should not fear changes, because their contributions always start with a branch that is to be reviewed prior to merging.

[vvasuki]

@vvasuki

I'm a bit surprised about the Git performance issues

* can you give an example of such giant changes?
  -Also, did you perform the rebasing out of the github webpage (i.e. relied on GitHub doing the rebasing)

This was more than 2 years ago and I hardly remember. Reading the OP, it seems that I was forced to do the rebasing on my computer rather than on GitHub (because the latter refused).

IMHO extracting components could lead to complications in managing the overall project.

My experience has been the contrary - git submodules make it all so simple. (For example, https://github.com/sanskrit-coders/jyotisha/blob/master/.gitmodules ) Also, just to contribute to skycultures, should it really be necessary to get the entire stellarium code (with history and prehistory by default)?

[axd1967]

This was more than 2 years ago and I hardly remember. Reading the OP, it seems that I was forced to do the rebasing on my computer rather than on GitHub (because the latter refused).

Looks like you faced "merge hell".

But I think there is a small problem with the way translations are organised in the source tree, and maybe you hit that problem. If I'm not mistaken, a part of the versioned files are actually generated or retrieved from external sources; such "generated" files should deserve a separate place in the source tree and should never be touched (and logically, they should never be versioned). Typically such generated files can give headaches (I hit it in #1205 (comment) until I realised that I was fiddling with files that should not be touched - again an indication that these files are in the wrong place).

IMHO extracting components could lead to complications in managing the overall project.

My experience has been the contrary - git submodules make it all so simple. (For example, https://github.com/sanskrit-coders/jyotisha/blob/master/.gitmodules ) Also, just to contribute to skycultures, should it really be necessary to get the entire stellarium code (with history and prehistory by default)?

Git submodules have their pro's and con's (see also #1295 ). But looking at the content, it looks like this could be an interesting use case for submodules.

Agreed, it is not small (eats 4.6Gb in my working tree...).

alex@xray:~/projects/stellarium/src/stellarium$ du -sch * | sort -h -r
843M    total
493M    po
121M    nebulae
45M     guide
38M     skycultures
25M     plugins
23M     scenery3d
21M     landscapes
17M     src
15M     textures
14M     stars
13M     data
12M     models
6.0M    util
5.4M    scripts
...

As one can see, it's the translations that take the lion's share. (Add to that a 3.8Gb .git/)

Splitting off skycultures might have another big benefit: it is easier to find the missing translations (see #1225 ) for a given skc.

A few additional notes

• if a submodule is absent/empty, don't include in the final compiled product, so that it does not clutter the compiled version. This is handy if I want to compile my version with just a minimum of cultures I need. In other words, skc are a true plugin.
• reorganise the sky cultures a bit: create a subdirectory for images, one for the descriptions,

western
├── asterism_lines.fab
├── asterism_names.eng.fab
├── CMakeLists.txt
├── constellation_names.eng.fab
├── constellationsart.fab
├── constellationship.fab
├── descr
│   ├── description.ar.utf8
│   ├── description.be.utf8
│   ├── description.bn.utf8
│   ├── description.zh_CN.utf8
│   ├── description.zh_HK.utf8
│   ├── ...
│   └── description.zh_TW.utf8
├── img
│   ├── andromeda.png
│   ├── antlia.png
│   ├── apus.png
│   ├── volans.png
│   ├── ...
│   └── vulpecula.png
├── info.ini
├── reference.fab
├── star_names.fab

So skc could be an interesting case for submodules ?

[axd1967]

Tangentially related, see https://github.com/Stellarium/stellarium-skycultures.

Using that repo as a git submodule might be a big leap, but the relationship with Transifex is unclear.

The .webp format is possibly not recommended for off-line application use; maybe it could be converted at build time to .png prior to packaging.