[Pkg-giraffe-discuss] z-push in experimental

[Carsten Schoenert]

Hi,

Am 21.09.2017 um 21:57 schrieb Roel van Meer:
>> So you can start to import the latest version of z-push and prepare a
>> new upload for testing. ;)
> 
> Should be ready:
> 
> https://github.com/roelvanmeer/z-push-packaging
> https://travis-ci.org/roelvanmeer/z-push-packaging
> 
> I've pushed this with a snapshot changelog from gbp, because I don't really  
> know what is good practice with regards to releasing and versioning.

I think this depends on some personal preference, there is no rule about
that. I try to not push such snapshot entries if not really useful and
count on the knowledge of the other maintainers to do own test builds.

A local snapshot build is really easy to set up. But for now it's fully o.k.

If you would change the last commit for debian/changelog to reflect a
version 2.3.8-1 to experimental I can do a upload on the weekend. The
commit looking fine.

> I've looked at lintian and everything packaging-related, but I haven't been  
> able to test the package itself in production yet.

Full blown packages (like kopanocore) with a large amount of binary
packages can't be tested manually in a complete way. This can only be
done by automatic tests. This can be done by the autopkg package. But
life comes to the autopkg only if we (mhh, realistically this "we" is
currently only you or additionally some people from upstream) put some
stuff into that so tests will done every time autopkg is called.
We can talk about this for sure at the Kopano Conference. Creating the
basic structure isn't very difficult.

> So, should I release this as 2.3.8-1 straight away, and put any fixes
> (if they are necesssary) into 2.3.8-2? Or should I push what I have
> now as an unreleased version and release it later? Or maybe don't
> push anything until I've had a chance to test it (at least
> somewhat)?

Right now the package is uploaded to experimental as it's possible it
may break other things, being unusable in the worst or simply not tested
well enough.
Given no matter you have done a lot of testing in preparation pre 2.3.8
and for the above reason I've chosen experimental as suite to upload I
guess it's o.k. to upload a 2.3.8-1 to experimental again without you
have done a real in deep testing again. In the end it's up to the
maintainer to decide if the package is "good" enough for being uploaded
somewhere. The barrier on experimental is the lowest, a upload to
stable-security is the most critical you can have. Also on this we can
talk at the conference.

> Do you have any advice or pointers to documentation?

Documentation is always good, as far I've seen the documentation dome by
upstream is up2date and has a high quality. I believe it would be a
waste of time to duplicate this. But the specific Debian details like
configuration of the packages, structure of the packaging will always be
useful for admins or users.

So I'd suggest to place some detail information beyond the existing
Kopano Groupware wiki page in a subpage. I'm thinking about

https://wiki.debian.org/Groupware/Kopano/Z-Push

By this we could concentrate all depending packages from kopanocore in
this name space later. And if needed we can simply move the page.

-- 
Regards
Carsten Schoenert