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

[Mattia Rizzolo]

On Tue, May 10, 2016 at 06:03:18PM -0400, Nicholas D Steeves wrote:
> > 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?

Well, you are not supposed to have your local master out of sync with
the remote one.  doing `git checkout debian/version-revision` detaches
your head from a branch, and the stuff you do that are only referenced
by the tag, yep.  But if you do a `git checkout master` you ought to go
back to the very place the remote master is, and doing stuff that means
pushing to the remote master, and stuff pushed there is going to be on
the next unstable upload.

> Had I made my mistake at this
> point, it seems like it would have been a huge mess!

I see it's easy to do something wrong by accident here ;)

> > given that now a branch is used instead the workflow is:
> 
> 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 "jessie-backports branch workflow" I keep as a reference is the one
used by devscripts, that actually keeps the old backports entry in the
changelog during the merge.

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

my idea of bpo is a series of separated forks, and here detached tags
work better than a branch.  But I think this is really a matter of how
you see it and how you work better, the actual thing doesn't really
change much.

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

Sorry for making this actually simple backport look like a huge
complicated deal :)

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160511/07d8abbb/attachment.sig>