Am Do., 2. Mai 2019 um 21:23 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
On Wed, 2019-05-01 at 23:53 +0200, Matthias Klumpp wrote:
Hello! Since last week, all of PureOS infrastructure is now switched to the latest, mostly Python-based version of Laniakea[1].
This is great news. Congratulations Matthias!
It's a major milestone, and I am incredibly happy about the reduced maintenance burden :-)
Laniakea also contains a message-bus based on ZeroMQ and JSON to let modules running on other machines know about changes and react to events when running in a more isolated environment. This also allows notifications via email or Matrix.
Do we intend to send messages to email and/or Matrix?
Mails aren't currently on my todo list, but if/when that feature is implemented I assume it will be subscribe-only or dependent on the user. E.g. we may send the user who caused a build failure an email, but not every single project member.
If so, perhaps we use a separate Laniakea channel for Matrix so as not to flood the PureOS channel. I suppose we can use the pureos-changes mailing list for messages too? pureos-project seems like it might be better left to higher level topics.
<snip>
When the feature existed for Tanglu back in the days, we had a #tanglu-changes IRC channel where messages were just dumped as-is. I imagine we could have that on Matrix as well. Sending build failures and results of QA runs to the mailinglist may be a lot of spam, I am not sure whether we should do that. The mailinglist currently holds direct changes to the archive (package uploads).
[...]
## What's next? ### Create an integration test framework for Laniakea We need better testing, or rather, any testing for some Laniakea modules and larger pieces of the codebase. Since a large chunk of Laniakea is interfacing with existing code or with its own modules, we need some way to do intergration testing properly.
When you say integration testing, what do you mean? Do you mean how the various components of Laniakea fit together?
Exactly that, as well as how those modules interact with other components such as dak, Britney, etc. I do not believe much in mocking components, so I am currently looking into how we could possibly test the whole thing and components working together easily. One such a test could be to automatically set up Britney, perform a run on a sample package repository, save the result to a temporary Postgres database, sort the data and assert the result.
### More unit testing! The Python code doesn't have many tests written yet, so this needs to be added as well.
I think a description of the test framework you use (TAP? PyTest), and then a TEMPLATE python script might be a great way to get folks to contribute. I know I would.
Having people write tests would be amazing, but probably also not the most fun task to start with ^^ At the moment I am thinking of using PyTest and Hypothesis[1] together, the latter of which I find very appealing from its approach.
[1]: https://hypothesis.readthedocs.io/en/latest/
### Bring back software.po.n (webswview) The web application just needs to be rewritten. This is a work in progress at time.
What is the framework for the web app? Is it Angular, Vue, or perhaps something from Python like flask?
It's plain boring Flask. I am not a web developer, and Flask is a thing that makes a lot of sense to me. Also, it can just directly use the ORM of Laniakea ;-)
### Package for Debian Laniakea should be available from withing Debian. This is a long-term goal as it requires at least some stability of the database schemas and more and better testing. Also, the JavaScript dependencies of the web modules need to be sorted out properly. Ultimately though, at some point you can just apt install Laniakea to create your own Debian derivative.
I think a lot of derivative would use this if you could just apt-get install laniakea. It ought to make their lives much, much easier. I know this would have helped Maemo when Nokia essentially abandoned it.
It's purpose is like a pluggable "Launchpad lite" - in theory you could have all features it provides with other tools, but that requires a lot more human work. In the long run I fear that I have to make Laniakea absorb dak to be as efficient as I want it to be, but I will try to avoid that as much as possible for now.
From long discussions last Debconf, Laniakea is exactly what many
projects and derivatives need, but unfortunately it's not ready yet to be used as easily as I want it to.
## What can I do? Contribute! Either by writing code for Laniakea (documentation is currently updated to reflect the Python changes)
URL? Are you using Readthedocs?
It's using MkDocs: https://lkorigin.github.io/ - the documentation hasn't been updated for about a year though, and really needs a complete overhaul. The documentation also requires some practical examples to do basic actions (e.g. scheduling builds with the CLI).
or filing bugs.
I filed a bug. You fixed it too quickly. :P
Neat :-D
Cheers, Matthias