[Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman

[Simon Hanna]

>>> 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