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

[Roel van Meer]

Carsten Schoenert writes:

> > 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.

Okay.
In this case I did, because I wasn't sure if anything else had to go into  
2.3.8-1 and I hadn't been able to test the builds, and leaving it off  
entirely would leave the repo in an inconsistent state (you'd have to update  
the changelog yourself or it would still try to build 2.3.7-1).

But personal preference, I can work with that. :)

> 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.

I'm very interested in this!

> 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.

I understand.
For now I'll concentrate on making a good package and I'll let you do the  
uploading. We can change that in a while when I've become more familiar with  
all the procedures and best practices.

> > 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.
> [snip]

Oh, haha, I meant documentation about these release procedures, pushing to  
Alioth and the like ;)

Thanks again,

Roel