[Pkg-giraffe-discuss] z-push in experimental (Re: z-push packages ready for uploading to NEW?)

[Guido Günther]

Hi Roel,
On Mon, Sep 25, 2017 at 07:38:42AM +0200, Roel van Meer wrote:
> Guido Günther writes:
> 
> > > 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've looked at lintian and everything packaging-related, but I haven't been
> > > able to test the package itself in production yet. 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)?
> > 
> > As a rule of thumb: don't upload completely untested software,
> > not even to experimental. You should at least be sure the package
> > installs, upgrades and runs with basic functionality. Otherwise this is
> > quiet frustrating to users of your packages.
> > To put out untested stuff we have the repository on alioth:x
> 
> That was actually what I was asking about: pushing to Alioth.
> 
> Say I add a commit to the current z-push version. I can push that to my own
> repo and ask Carsten to review it and push to Alioth (which is the current
> state of affairs) but I reckon this is not how we want to keep things for
> very long.
> 
> So maybe I should rephrase my question..
> 
> If I have one or more commits that should end up in the Z-push repo, should I
> 
> a) push only those commits to Alioth (keeping the changelog as it is)
> b) push those commits to Alioth, ending with a commit that updates the
> changelog (with an UNRELEASED snapshot version)
> c) hold my commits locally until I've had a chance to fully test everything,
> and then push them to Alioth, ending with a changelog entry for a new
> release.
> 
> I think option b) would be best, since c) doesn't help collaboration and a)
> leaves you with incorrect or inconsistent versioning if you rebuild from
> Alioth locally. However, b) can result in some more updates to the changelog
> file than the other two.

Both a) and b) work. If you prefer to commit the changelog that's
o.k. gbp dch will pick that up correctly. If you prefer to not generate
a changelog that's o.k. either since somebody checking out git should
run a "gbp dch -S -a" anyway.
That said b) is more explicit since it tells even occasional
contributors that it's not a finished version. But makes reverting
and cherry-picking commits a bit more effort. Since we don't have this
problem yet (we're only maintaining a single branch) I'd go with b).

Cheers,
 -- Guido

> 
> 
> Thanks, and see you Wednesday.
> 
> Roel
> 
> _______________________________________________
> 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
>