[Pkg-giraffe-discuss] Z-Push trademark license

[Mark Dufour]

Hi all,

It took us some time unfortunately, but we have finally added a LibreOffice-style trademark license to Z-Push, 
and it's basically the same as what we did for Zarafa before:

https://stash.z-hub.io/projects/ZP/repos/z-push/commits/e7ee2d4cd0f6f0631c78165841bd757b8dbe61f3
 
See especially LICENSE and TRADEMARKS in the root.

I hear that the 'prefinal' release containing this commit should be out within a week or so, and a final
release somewhere in december..

So from then on it should be fine to use the Z-Push name in Debian. Please let me know if there's still something 
we should improve before the next Z-Push release.

Thanks to all those involved, and for those offering their help packaging Z-Push, as this greatly improved the 
motivation to go and talk with lawyers.. ;-)

I kind of lost track in the meantime of the discussion here I'm afraid..


Cheers,
Mark.
 
-----Original message-----
> From:Carsten Schoenert <c.schoenert at t-online.de>
> Sent: Tuesday 25th October 2016 19:05
> To: Felix Bartels <f.bartels at kopano.com>; Sebastian Kummer <s.kummer at kopano.com>
> Cc: pkg-giraffe-discuss at lists.alioth.debian.org
> Subject: Re: [Pkg-giraffe-discuss] Update von d-push/z-push in Debian testing?
> 
> Hello Felix,
> 
> On 24.10.2016 11:28, Felix Bartels wrote:
> > As far as I can see the package layout you are speaking about was
> > only used in the unreleased Z-Push 2.1 update, but not in the
> > currently distributed packages (as can be seen here
> > https://packages.debian.org/search?keywords=d-push&searchon=names&suite=all&section=all).
> > Is it then still necessary to have transition packages for this
> > layout?
> 
> yes and no. :-)
> The Debian packages I was speaking are the packages that would be
> created by the latest update and upload within the Debian git packaging
> tree. That was done by Wolfram in February 2013 right after the upload
> of 2.0.7-1, and yes, that would be version 2.1.0 [1].
> That's of course far away from the current needs and provided packages
> by Zarafa/Kopano.
> 
> And version 2.0.7-1 is the used version in Jessie we have to take care
> of that. And even more. If we want to meld the Debian packages from
> Zarafa/Kopano we need to take more care.
> But that's not a real big problem, that's why there are fields like
> Depends, Provides, Replaces and Breaks. We "only" need to collect the
> needed packages and version dependencies to fill there.
> 
> > A development writeup about the z-push provided packaging can be
> > found on https://wiki.z-hub.io/display/ZP/Packages and
> > https://wiki.z-hub.io/display/ZP/Installation. This also mentions
> > that the packages you are missing in your overview are now
> > unsupported and therefore no packages are built for them.
> 
> Thanks, I haven't noted this yet. That's helpful.
> 
> > While we designed the package layout how we see it fit, we are more
> > than open for feedback and suggestions on how to make this easier to
> > comprehend for admins. Imho the main goal should be to have both
> > packaged builds mirror each other closely, so that users could easily
> > switch from one to the other.
> 
> I would go one step further. There should be only one place for the
> packages. If you are familar with the main tool we use -
> git-buildpackage - you will see the enormous flexibility given by that.
> 
> > The goal of this package layout on the other hand was to give admins
> > the possibility to install only the packages they really need. Z-Push
> > 2.3 for example introduced the possibility to have volatile states
> > (used for loop detection) in memcache instead of using php
> > shared-memory (which is still the default if both are installed).
> > This reflects in on package z-push-ipc-sharedmemory (in your example
> > this would have been part of d-push-common) and one dedicated
> > z-push-ipc-memcached.
> 
> As written, I would tear down the amount of packages. But that should
> depend in the end on the maintainers of the packages. We will see what's
> best.
> 
> > Having multiple config packages for webserver configuration seemed
> > for us the easiest approach to satisfy the need to support multiple
> > webservers (without directly supplying configuration examples for all
> > these servers).
> 
> I was thinking the same in days before I've done some packaging on that.
> My minds have changed on this as I've see the great possibilities given
> the mechanisms of apt/dpkg.
> 
> For example a admin can control the preferred webserver to use even if
> z-push would use for example a
> 
> Depends: apache2 | nginx | lighttp| http
> 
> Simply install the desired webserver by
> 
>   apt install nginx z-push
> 
> That would install ngix instead of apache2, even as the first line in
> the Depends field is Apache2. Just put all configuration files for the
> webserver into the package and install them into the right place.
> By this there is no need for three config packages.
> 
> [1] https://anonscm.debian.org/cgit/pkg-giraffe/d-push.git/log/
> 
> -- 
> Regards
> Carsten Schoenert
> 
> _______________________________________________
> Pkg-giraffe-discuss mailing list
> Pkg-giraffe-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-giraffe-discuss
>