next changelogs and ppa uploads

[Scott Kitterman]

On Monday, September 22, 2014 14:36:27 Harald Sitter wrote:
> On Mon, Sep 22, 2014 at 2:29 PM, Scott Kitterman <ubuntu at kitterman.com> 
wrote:
> > On Monday, September 22, 2014 14:18:33 Harald Sitter wrote:
> >> On Mon, Sep 22, 2014 at 2:09 PM, Scott Kitterman <ubuntu at kitterman.com>
> > 
> > wrote:
> >> > On Monday, September 22, 2014 13:54:04 Harald Sitter wrote:
> >> >> On Mon, Sep 22, 2014 at 1:47 PM, Scott Kitterman
> >> >> <ubuntu at kitterman.com>
> >> > 
> >> > wrote:
> >> >> > On Monday, September 22, 2014 13:41:32 Harald Sitter wrote:
> >> >> >> On Mon, Sep 22, 2014 at 1:18 PM, Scott Kitterman
> >> >> >> <ubuntu at kitterman.com>
> >> >> > 
> >> >> > wrote:
> >> >> >> > On Monday, September 22, 2014 12:12:36 Harald Sitter wrote:
> >> >> >> >> I'd like to propose that *all* ppa uploads of next workspace get
> >> >> >> >> a
> >> >> >> >> changelog entry.
> >> >> >> >> 
> >> >> >> >> objections?
> >> >> >> >> 
> >> >> >> >> in fact, what are everyone's thoughts on doing this on general
> >> >> >> >> principle and have a script to then compress ppa entries into
> >> >> >> >> one
> >> >> >> >> version when/if it gets uploaded to the archive?
> >> >> >> >> 
> >> >> >> >> right now its an outright mess as one has to check a notes page
> >> >> >> >> or
> >> >> >> >> ultimately the ppa to find out what ~ppa version is the latest
> >> >> >> >> of a
> >> >> >> >> given package, having multiple ppas where things could be
> >> >> >> >> doesn't
> >> >> >> >> really help either.
> >> >> >> > 
> >> >> >> > Let's see the script that compresses the changelog entries first.
> >> >> >> >  A
> >> >> >> > PPA
> >> >> >> > upload changelog ought to be uploadable to the archive once the
> >> >> >> > ~ppaX
> >> >> >> > is
> >> >> >> > removed.
> >> >> >> 
> >> >> >> Let's make a decision before we have someone waste their life on
> >> >> >> it,
> >> >> >> shall
> >> >> >> we?
> >> >> > 
> >> >> > OK.  Since next workspace is PPA only for some time, I think it's
> >> >> > reasonable if there's a script up to when we do the first uploads to
> >> >> > the
> >> >> > archive, then I think we should do it like other packages where the
> >> >> > debian/changelog entries are pre-compacted.
> >> >> 
> >> >> Mhh, how about putting a metadata file in the relevant branches then?
> >> >> The file would always contain the latest version.
> >> >> cat _ppa_version
> >> >> 
> >> >>   4:5.0.1-0kittens11~spaceships100~ppa6
> >> >> 
> >> >> There's really only those two options IMO. We have to put the data
> >> >> somewhere>>
> >> >> 
> >> >> :S
> >> > 
> >> > I don't think I'm following you.  What goes in this file that's not
> >> > already in the changelog?
> >> 
> >> Versions of ppa uploads are not in the changelog. What we are doing is
> >> we have a forever unreleased changelog entry for what will eventually
> >> go into the archive. The actual versions that are being uploaded to a
> >> PPA are not tracked, the ppa-bzr-build-package script temporary merges
> >> source and packaging and injects a temporary changelog entry which
> >> never ends up in bzr.
> >> 
> >> Since you don't want the PPA versions tracked in the changelog for
> >> things that eventually go to the archive we have to put the
> >> information somewhere.
> >> 
> >> Concrete example: earlier I changed the plasma5 systemsettings package
> >> and needed to lookup the version that is our latest PPA upload. So I
> >> went to the next ppa, which had 5.0.1, while the changelog had 5.0.2
> >> (that already required me as faulty human to realize that), so I had
> >> to go to next-staging find systemsettings, filter a bit and finally I
> >> found the correct version.
> >> In fact this is even an even more general problem for ppa uploads, if
> >> I fix something in a PPA-only package version (e.g. a backport) I need
> >> to know the previous ppa version in order to generate a new upload,
> >> currently this involves a human somehow finding out what the previous
> >> upload was.
> > 
> > Is it just the latest version number in the PPA?
> 
> Yes.
> 
> >  If so, can't you get that
> > 
> > programmatically from LP?
> 
> Yes
> 
> >  That would seem even less prone to error.
> 
> Besides random timeouts for no good reason, keyring unlocking queries,
> connection resets and the fact that one would have to query multiple
> PPAs with >100 sources each, sure. ;)
> 
> (yes, I have done too much launchpad scripting)

Fair enough.  Launchpad sucks is a great reason to keep the metadata in bzr.

Scott K