gemmellr commented on PR #225: URL: https://github.com/apache/qpid-broker-j/pull/225#issuecomment-1772859490
Considering we have never had a single image all this time, this feels over elaborate as a starting point. Are there seriously going to be 192 image variants with the different os/jvm/protocol/store options as described? That seems excessive. Which ones would actually be getting pushed and why? The 'protocol' images having amqp-all, amqp-0-8, amqp-0-10, amqp-1-0 means it doesnt even allow picking e.g just AMQP 0-9 or 0-9-1 (and doesnt make it obvious the 0-8 one would probably actually include them). The broker already allows selecting specific protocols through its configuration, so I dont see a good reason to complicate things by having 4 (or 6..so make that 288 variants?) different image variations for that. If someone wants a seriously customised image with different protocol deps in it then they can easily [/continue to] roll their own. For everything else they can just configure it. I also see no good reason to have a postgres specific image (or derby, or memory store either). Are we going to add one for every DB someone likes and explode the matrix of image options even further? We dont even test with postgres at all so its unclear why would we ever have that as a default image option to begin with. Having a single basic out-the-image setup that gets people started, like the regular broker distribution does itself, and then having ways for people to easily supply custom config (including users if appropriate, as opposed to the hard coded ones) to use instead to meet their specific needs, seem easier to justify and maintain later, while actually being more general for people to get whatever behaviour they want and without needing yet more image variants to be created later. Even the 4 OS and 3 JVM options seems a bit much. As comparison, some other Apache projects with brokers that also only started deploying images this year, currently have 1 or 2 images that they actually push, and perhaps a few for local dev that they dont. That seems like a more appropriate path to start with. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
