RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 10 May 2016 at 11:17, Mattia Rizzolo <mattia at debian.org> wrote:
> Sorry for the delay, these days are crazy for me....

That's life, right?!  :-)

> On Fri, May 06, 2016 at 02:05:17PM -0400, Nicholas D Steeves wrote:
>> I've just purged that repo and uploaded a bpo of libsndio to mentors.
>
> mh, no.
>
> There is already one in bpo-NEW from 2 days ago :)
> https://ftp-master.debian.org/new/sndio_1.1.0-2~bpo8%2B1.html
>
> So, I'm going to use a local bpo of sndio instead (also because yours
> would not be nice to upload due to the +2.  why 2 identical changelog
> entries??), and try to build audacious again.  Tomorrow first thing in
> the morning most probably.

;-) That's mine.  I contacted Peter Piwowarski asking if he'd like me
to maintain a backport as soon as I realised that an audacious bpo
depended on having a sndio bpo in the archive.  I'm not sure where two
identical changelog entries for bpo+1 and bpo+2 came from...that's
very strange.  Thankfully my sponsor caught it during the application
process!

>> Message-ID: <CAD=QJKhx07NQ17gNOEowi24VDreHY-nj52UNCTrv1e1UiSAZzw at mail.gmail.com>
>
> On Thu, May 5, 2016 at 3:19 AM, Nicholas D Steeves <nsteeves at gmail.com> wrote:
>> Thank you very much for fixing the mess I made.  To maintain this
>> backport, is the following sequence of commands appropriate?:
>>
>> git checkout --detach --rebase debian/version-revision
>
> actually --detach shouldn't be needed at all, and I can't really see
> what --rebase would do here (also because it's not even in
> git-checkout(1))

It seems I somehow mixed up git-checkout and git-rebase.

> Now, umh, with `push debian/%(bpo_tag)s would be what I usually do
> without a branch.

Ohhh, I think I'm starting to understand now.  So what happens that
the local master branch gets ahead of the remote without --detach, but
that's ok.  It's ok because git pushes a snapshot of the local changed
state to a remote state is only referenced by the tag.  If for some
reason there was a bug in the debian/%(bpo_tag)s version, that's not
in the debian/version-revision...well, that's where it feels strange
to me.  So then one would make further changes to the local repo,
local master would get further out of sync from remote master, but
that wouldn't matter because the local state of master is only ever
reflected as a tag on the remote?  Had I made my mistake at this
point, it seems like it would have been a huge mess!

> given that now a branch is used instead the workflow is:
>
> git checkout jessie-backports               # enter the bpo branch
> git merge debian/version-revision          # merge changes since last bpo
>                                                           # this might lead to
>                                                          # conflicts in changelog, but
>                                                          # nothing impossible.
> dch --bpo                                           # update changelog
> gbp buildpackage --git-tag                  # build+tag
> git status
> git add                                              # same as above
> git push                                             # push the current branch
> git push --tags                                   # push the tag

This makes sense to me, but I'm still unclear why "git checkout
jessie-backports && git merge debian/version-revision" is preferred
over "git rebase debian/version-revision", when version-bumping the
bpo.  I guess the question is: For a version bump of a bpo, should the
changelog of a new-version bpo mention the previous bpo, or should it
only contain a single "Rebuild for $stable-backports" entry?  The
semantics of checkout+merge seem to favour a bpo changelog that
mentions prior versions (independent parallel branch with coherent
history and imported updates), while the semantics of git rebase seem
to favour a series of bpo forks (branch is a history of forks).  I've
consulted this doc: https://git-scm.com/docs/git-rebase

Mattia, thank you for taking the time to help me understand,
I appreciate it a lot,
Nicholas