3 ms·

OP here. You can learn about what makes up a Zulip server here: https://zulip.readthedocs.io/en/latest/overview/architecture-overview.html https://zulip.readt

OP here. You can learn about what makes up a Zulip server here: https://zulip.readthedocs.io/en/latest/overview/architecture-overview.html https://zulip.readthedocs.io/en/latest/overview/architecture... (and get a lot more detail if you browse around the rest of our 120K words of developer documentation). I have a great deal of Debian packaging experience (I used to maintain over 100 Debian packages for MIT's Debathena project, mostly powered by the config-package-dev project that I'm a co-author of; and then later 20+ in Debian itself as part of getting Sagemath into Debian; and I maintain the handful of Zulip dependencies that we ship versions of in our Ubuntu PPA), and so I have a pretty good sense of what does and doesn't work well with the Debian (and RHEL) style packaging models. I'd love to support native packages for every platform, but it's a huge amount of work (especially on the maintenance side, since one needs to do QA for each platform's upgrade process) that comes out of the time we can spend on making Zulip a better product. And the result is likely to be less good error-handling; I'd rather have an installation/upgrade process that just works (and if it can't because of some problem beyond our control, like the server not having enough RAM or disk, gives a clear error message that explains the problem to the user) but is limited to one platform (which anyone can easily get; virtualization is 20 years old at this point!), than support lots of platforms but be constantly fixing little issues with the other ones. Which isn't to say that we won't support e.g. RHEL in the future (we probably will), just that it's costly to do so, and the "Use an Ubuntu VM or container" solution works pretty well for most folks. That said, we're open source (and an open community!) and anyone who's worked with Zulip knows that I'm very happy to provide detailed technical advice and do code review to help things like this happen.

ciupicri 8y ago
That and this page [1] mentioned by zerkten, are what I wanted. Too bad I didn't find them in the first place. Maybe they should be mentioned in the page I've complained about. I'm familiar with RPM packaging, so I feel you pain. I understand that you don't have native support for every platform, after all you probably don't support Windows :-) What puzzled me was the lack of instructions, so that others could at least try making Zulip work on their system. [1]: https://zulip.readthedocs.io/en/latest/development/setup-advanced.html#installing-directly-on-ubuntu https://zulip.readthedocs.io/en/latest/development/setup-adv...
- tabbott 8y ago
  Those instructions are for the development environment which is simpler in a few key ways (e.g. one doesn't need to deal with SSL certificates). But yes, that'd be the starting point for a production installer for other platforms.

ciupicri 8y ago

That and this page [1] mentioned by zerkten, are what I wanted. Too bad I didn't find them in the first place. Maybe they should be mentioned in the page I've complained about. I'm familiar with RPM packaging, so I feel you pain. I understand that you don't have native support for every platform, after all you probably don't support Windows :-) What puzzled me was the lack of instructions, so that others could at least try making Zulip work on their system. [1]: https://zulip.readthedocs.io/en/latest/development/setup-advanced.html#installing-directly-on-ubuntu https://zulip.readthedocs.io/en/latest/development/setup-adv...

tabbott 8y ago
Those instructions are for the development environment which is simpler in a few key ways (e.g. one doesn't need to deal with SSL certificates). But yes, that'd be the starting point for a production installer for other platforms.