Rolling releases for Container Images and Funding Campaign for Mailman

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.

On Sun, Nov 12, 2017, at 08:06 AM, Simon Hanna wrote:
Yes, that is a totally possible scenario.
But, given that kind of testing we currently do, this scenario can happen not only to git-heads but also releases. That is what I am trying to build using container images.
The fact that I *announced* and *released* these rolling images for public use, is only because people asked for it before. These images come with a fair amount of warning that, right now, they can break!
It would most definitely be a pain if we were to break REST API frequently, but that is quite rare. Given that in future API will be consumed by not just us, it is important to keep this assumption true.
Another wishful project I have is to be able to "map" the REST API and monitor for changes; it'd also help us with lemme (the authenticating/authorization proxy for Core).
And yes, container images will fail, and that's the point! I want them to fail so that releases don't :)
Rolling images are meant to bring a faster feedback-loop from users who are OK with rare occasional breaking and want to help test the software, something like public-beta releases.
Incompatible changes are released only with major version upgrades, so it is not going to happen with everyone, unless they choose to use the git-heads and get themselves into it.
Yes, we definitely don't want to say "use new beta-quality container images or stone age stable release". Going forward, we will have more frequent releases too :)
Containers are just an easy way to scale, given that we already have them, it'd be fun to see if I can make multiple instances run in parallel. Given that _most_ parts store their data in a data store (database, redis etc), it shouldn't be too difficult. There will be quirks with logging, queues in Core and hence held message views in Postorius, but apart from that, I think everything else can be served using any random instance of Core/Postorius/Hyperkitty.
We can most definitely run multiple instances of Hyperkitty, which I feel will be more used than any other part of UI. If we partition the data smartly, we could do the same with Core.
Again, these are just theories and needs much more testing and some changes in components themselves! This would most definitely increase the availability and auto-scaling.
Making Core's API more efficient would definitely be a good thing and we do intend to do that in future. But, this would still be relevant if we had an efficient REST API, it's not a band-aid to the actual problem :)
-- Abhilash Raj maxking@asynchronous.in

On Nov 12, 2017, at 11:06, Simon Hanna <simon@hannaweb.eu> wrote:
Scenario: Core changes something about rest that is backwards incompatible. The change is commited to master.
The REST API is versioned, so it would be a bug to introduce a backward incompatibility in the same API version. That’s why for example a new API version was introduced to handle the UUID data type change. There was no way to make that backward compatible, so we had to bump the API version, but we didn’t remove the old API version so clients written against that still work. Adding a new API generally doesn’t require bumping the API version.
Cheers, -Barry

On Sun, Nov 12, 2017, at 08:06 AM, Simon Hanna wrote:
Yes, that is a totally possible scenario.
But, given that kind of testing we currently do, this scenario can happen not only to git-heads but also releases. That is what I am trying to build using container images.
The fact that I *announced* and *released* these rolling images for public use, is only because people asked for it before. These images come with a fair amount of warning that, right now, they can break!
It would most definitely be a pain if we were to break REST API frequently, but that is quite rare. Given that in future API will be consumed by not just us, it is important to keep this assumption true.
Another wishful project I have is to be able to "map" the REST API and monitor for changes; it'd also help us with lemme (the authenticating/authorization proxy for Core).
And yes, container images will fail, and that's the point! I want them to fail so that releases don't :)
Rolling images are meant to bring a faster feedback-loop from users who are OK with rare occasional breaking and want to help test the software, something like public-beta releases.
Incompatible changes are released only with major version upgrades, so it is not going to happen with everyone, unless they choose to use the git-heads and get themselves into it.
Yes, we definitely don't want to say "use new beta-quality container images or stone age stable release". Going forward, we will have more frequent releases too :)
Containers are just an easy way to scale, given that we already have them, it'd be fun to see if I can make multiple instances run in parallel. Given that _most_ parts store their data in a data store (database, redis etc), it shouldn't be too difficult. There will be quirks with logging, queues in Core and hence held message views in Postorius, but apart from that, I think everything else can be served using any random instance of Core/Postorius/Hyperkitty.
We can most definitely run multiple instances of Hyperkitty, which I feel will be more used than any other part of UI. If we partition the data smartly, we could do the same with Core.
Again, these are just theories and needs much more testing and some changes in components themselves! This would most definitely increase the availability and auto-scaling.
Making Core's API more efficient would definitely be a good thing and we do intend to do that in future. But, this would still be relevant if we had an efficient REST API, it's not a band-aid to the actual problem :)
-- Abhilash Raj maxking@asynchronous.in

On Nov 12, 2017, at 11:06, Simon Hanna <simon@hannaweb.eu> wrote:
Scenario: Core changes something about rest that is backwards incompatible. The change is commited to master.
The REST API is versioned, so it would be a bug to introduce a backward incompatibility in the same API version. That’s why for example a new API version was introduced to handle the UUID data type change. There was no way to make that backward compatible, so we had to bump the API version, but we didn’t remove the old API version so clients written against that still work. Adding a new API generally doesn’t require bumping the API version.
Cheers, -Barry
participants (3)
-
Abhilash Raj
-
Barry Warsaw
-
Simon Hanna