These images are built using git-heads *only* if they are passing our test suite and are re-generated weekly. You should be aware that while all these components are tested with their individual test suites, their combination might sometimes not be stable. This will get you updates/bug-fixes much faster :) This contradicts what you said in my merge request for Postorius https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756
You either use released versions, or make sure that the master branches are always compatible. You can't have both with the current development model. Not exactly, I still believe all our git-heads should be compatible with released (i.e. stable) versions of dependencies, regardless of the fact that we maintain those dependencies.
Also, there is at least one test per-project which tests with git-heads of dependencies we maintain, so that we know if we make any incompatible changes.
I am not sure what in the current development model prevents us to do both?
The story for container images is different than testing with git-heads. We need better integration testing for the entire suite to be stable in conjunction, rather than independently. In fact, containers might be the perfect way to actually do the integration testing. Scenario: Core changes something about rest that is backwards incompatible. The change is commited to master. Since your containers use the master branches, all future builds will fail until mailmanclient and postorius/hyperkitty. If you want to always have Postorius (and others) compatible with the latest release of master, development for Postorius will be a Pain, because you can't use the master branch of mailman for testing and quick changes. Also your containers and all integration tests that can be done with them will always fail.
Until you fix Postorius and the other clients... So why not just have the master branches always compatible and make life easier for developers. I don't see a good reason why you want to do it the other way round...
Any bug in core that affects Postorius will also just remain there until you release a new version of core.
If you really really want to have it your way, there have to be more frequent releases.
- Improve the container images to work with new micro-services architecture, to achieve scaling and redundancy in services. The current bottleneck is the rest api from core. IMO bulk actions, filtering and sorting should be added there before trying to have multiple postorius/hyperkitty instances serving the same core... I didn't say they will be served from the same core ;-)
Yes, the Core's API can be further improved to be more efficient. But that doesn't prevent us from scaling. I understand there are issues around multiple instances of containers, but I have ideas to get around most of them. I just don't want that people that have issues with big installations get the answer: We know of that issue, please deploy Mailman on X containers/machines as a workaround