Hello Simon, I'll add the bug report to the recipients so other can are also see this mailing.
As you see I'm answering time shifted, it's the time of the year were more things pop up that needs to be done as usual. Am 07.12.20 um 12:29 schrieb Simon Eisenmann: > Hey Carsten, > > thanks for including me in this. I understand why you want to orphan > kopanocore completely and also agree that it would be the for the > best. We will also have an internal discussion about this.> > Generally we improved our release situation a bit with the announce > of Kopano One and everything related to it but from a Debian point of > view, the releases are still too frequent and hard too follow. Frequent releases aren't a real problem. I appreciate them, they show mostly an active and healthy upstream project. For Kopano the underlying team in Debian is currently based on only two persons, Guido and myself, no new contributors came up. In the past Mark has done a great job to simplify the workload on our side by providing information, useful tips, intermediary and some kind of glue from Debian to upstream. I personally don't use Kopano as it's functionality is to much for me, I don't need most of the features. I've done all the work just for fun and because Kopano is the first big alternative for M$ Exchange. > Our stack has always been complex and i am wondering if it were worth > the effort for the users to actually have a 100% feature complete > Kopano in Debian at some point under the assumption (like you stated) > that our stack is using broadening its use of technologies (Go, Node, > Rust ..). Complexity isn't really matter (and shouldn't) in my eyes. We have other complex packages in the archive which are the wide ground the distribution is build up. It took up years but today you can run e.g a GitLab instance only with packages from Debian. And I don't see a real reason why Kopano could not be part of Debian, currently the only preventing thing is the man power to drive all the things. Even if you (Kopano) is using their own repository to provide packages for their costumers I see a big gain in the maintenance of required packages of Kopano direct dependencies if Kopano would like to improve the situation on this. Kopano isn't the only company that is maintaining some additional packages on their own to provide the full usability of their own packages. But in some cases these additional packages are breaking the update process of the underlying system, or at least bring in some side effects. This ends that users need to run and administrate machines that are exclusive for third party software. I see such systems on my day job and such machines are cost a lot of time and are always some kind of special. I also see that Kopano is building their own packages based on more than the usual C/C++ stuff, so it's not that this work isn't already done. It's just a small step to do this work upstream (means manage these packages in Debian) and get the added value quite automatically in all supported releases and also into Ubuntu. We happily sponsor package uploads, we've done this for z-push now for over 3 years. Thanks to Roel who prepared mostly all uploads. > A fully functional Kopano system would include: > > - Kopano Server and related software (kopanocore, libkcoidc, gsoap + > patches, libical + patches, libvmime + patches) You mentioned here three packages with additional patching, so far I understand. :) And gsoap isn't a corner package. That's exactly the situation I mean. The gsoap maintainer is very responsive and open minded for issues like that, this was my impression I've made in the past were we had a similar situation. libvmime is different, we don't have seen a release (again) for two years. > - Kopano Web server (kweb) > - Kopano Web apps (webapp, newer progressive web apps) > - KDav > - Z-Push > > How do you see this from the Debian perspective - is it even feasible > or wanted to have a stack like this including all its build > dependencies (which are probably like 2000 individual things if you > cound Javascript modules) - what is the Debian position on this? I think the situation for Debian is relatively simple and driven by the DFSG. As long software is complaint to these rules there are no reason why we don't include this software. The above list isn't much differing from the current package situation. I only see directly a new library libkcoidc as a new dependency which need to get packaged. But yes, quite a lot of time can be spend on unravel PHP and JS dependencies to not ship big blobs of required additional packages. > At Kopano we solve this problem by having a build pipeline which has > a pre-build step which fetches all the dependencies using the > corresponding system (Go, Node, Rust) and as a second step package it > which makes it rather easy. Debian knows that projects tend to do this, but as you also know for sure the view on this by Debian is that this model isn't really cost free. As long as we talk about PHP and JS we always need to talk about security aspects. And in my eyes this is only solvable if projects doesn't ship their own copy of such modules or build up their software in a way we can use packages software instead, I know this isn't always and easy possible. As you might remember, also Kopano Webapp was hit by a security issue due a outdated shipped additional component. And solving this has made some work I alsways like to spend on other things. > I would be very interested to hear your opinion if there is actually > a feasible way to get something like this into Debian or if it rather > should be kept separate for good. This very much depends if Kopano would like to have packages of Kopano in Debian unstable/testing/backports/stable. And this depends in my eyes which way Kopano like to go. I see no problem in having Kopano packages in Debian and Kopano is providing service to their costumers based on these packages by helping to administer the Kopano ecosystem on such machines. As we all know earning money is mostly done by providing service, not only by selling new products. If Kopano thinks having packages in Debian (and it's downstream) would be good and preferable I personally like to see we are working better together by making decisions together and also work on packaging together. Guiding Kopano people to given DM rights would be a nice thing. -- Regards Carsten
