Poll: CelestiaContent

[SevenSpheres]

In January, onetwothree split Celestia's code and content repositories on GitHub. The reasons for this can be seen in that thread, but I think it was poorly thought out and causes more problems than it solves, specifically:

• I'm still not sure how compiling/installing Celestia will work with two separate repositories.
• Two months later, CelestiaContent still hasn't been finalized and there are still data files in the main repository.
• It's unclear which files should go where; e.g. celestia.cfg is in the main repo, and so is the README file (although onetwothree is now saying that README should be in CelestiaContent!)
• Related to the above, data maintainers (e.g. me I guess) often have to make two pull requests to update things.

So I'm making it a poll. What does everyone else think?

[LukeCEL]

Personally I don't think it makes it easier to update the content. A lot of times the source code needs to be updated too, like when there's a change to celestia.cfg, or when there's an associated script that generates the file. I don't like having two PRs: one to update src/tools, and one to update the actual files.

[SevenSpheres]

Personally I don't think it makes it easier to update the content.

Neither do I. In the poll option I'm referring to "updates" for end users, since that seems to have been onetwothree's main reason for the split.

A lot of times the source code needs to be updated too, like when there's a change to celestia.cfg, or when there's an associated script that generates the file. I don't like having two PRs: one to update src/tools, and one to update the actual files.

Yep, this is exactly one of the problems I refer to in the OP.

[onetwothree]

I'm still not sure how compiling/installing Celestia will work with two separate repositories.

Easy. You simply install 2 packages. Actually even before splitting we had 3 packages: 1st with binaries, 2nd with common files e.g. translations, shaders, etc and 3rd with data, e.g. textures, models and catalogues. We also have a meta-package which depends on all of them. Now I have all required files to build data package for Debian using the new repository. I just forget to contact munix9 to update his spec files for OpenSUSE and Markerz regarding macOS bundle.

Two months later, CelestiaContent still hasn't been finalized and there are still data files in the main repository.

That's because we build packages only using the main repo still.

It's unclear which files should go where; e.g. celestia.cfg is in the main repo, and so is the README file (although onetwothree is now saying that README should be in CelestiaContent!)

One README contains information regarding source code, another one is for data files. They are 2 quite different files. You can remove code related information from current README and copy it to data repository.

Related to the above, data maintainers (e.g. me I guess) often have to make two pull requests to update things.

You may consider me rude, but you guys waste much more time discussing useless topics like who should have what colour in discord and here.

[SevenSpheres]

One README contains information regarding source code, another one is for data files. They are 2 quite different files. You can remove code related information from current README and copy it to data repository.

So what happens when installing files? One file named README overwrites the other file named README??

The whole thing is just a poorly thought out mess.

[onetwothree]

They will be in different directories.

[Lafuente_Astronomy]

I do think they are a mess but that's because of the lack of developers. Perhaps if some corrections and fixes to the code are implemented, it my be justified as separated. Hence, why I voted to keep them separate. But that's just my 2 cents. I'd defer to the devs on this one

[SevenSpheres]

I'd defer to the devs on this one

Remember Luke's words on Discord...

And I defer to selden because I myself do not have such knowledge on these things

Currently we are talking about organization. If you have good ideas on how to organize, please contribute! I think that's all that's needed for this conversation, no deep knowledge or expertise needed.