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

[Nicholas D Steeves]

Sorry for the delay.  Life... ;-)

On 10 May 2016 at 20:16, Mattia Rizzolo <mattia at debian.org> wrote:
> 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.

Ahh, so that's how you do it!  Git checkout tag detaches from a branch
and updates to that state; subsequent git checkouts will not checkout
anything, unless the tag is forcefully updated (bad!).  Git checkout
branch attaches to that branch and updates; subsequent git checkouts
bring the local repo up-to-date with that branch.

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

Is the "jessie-backports branch workflow" what you provided in a
previous email?  Used by which devscript?  Dch?  If the workflow is
different than what was shared, could you please tell me where I can
read it?  I'm guessing that this will be what happens over time, to
debian/changelog:

Tagged bpo changelogs will only have one "Rebuild for jessie-backports" entry.
All these entries will somehow be prepended to the changelog in the
jessie-backports branch?
Or will the debian/changelog on the jessie-backports branch be
identical to the latest tagged bpo?

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

I've been (locally) experimenting with both approaches.  I still think
I'm doing something wrong with detached tags!  For example, suppose I
fix spelling errors in some package of v4.5.3, and want to backport
those changes to v4.5.2:

git checkout v4.5.3
(make changes. eg: update changelog with an obvious marker)
git add -u
git commit

git checkout v4.5.2
(warning)
git stash
git checkout v4.5.2
git stash pop
(resolve conflicts)
git tag -a v4.5.2.1 -m "Backport trivial spelling fixes from v4.5.3"
git add -u
git commit
--

At this point, what I found was that if I do a checkout master, and
then do a checkout v4.5.2.1, then my changes are lost.  The only way I
can get back to them is by doing a checkout cce2f0d.  Git tag -l
--contains commit cce2f0d prints nothing.

git tag -f v4.5.2.1 cce2f0d
prints
Updated tag 'v4.5.2.1' (was 09846dc)

Now I can get back to the intended detached state using the tag.  My
concern is that with the following instructions:

On 10 May 2016 at 11:17, Mattia Rizzolo <mattia at debian.org> wrote:
> 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

The tag happens before git add, thus necessarily before the commit.
>From my experiments, it seems like when I git push --tags, the tag I
push will point to the wrong commit.  Am I doing something wrong?  It
doesn't seem like manually forcing a retag->correct_commit before
pushing is part of a normal workflow.  Or is it?

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

:-) Arguably, the most important thing learned by joining a team is
how to work "as a team"!  A simple case like a backport is perfect for
this.  If there's a checklist of things in which one needs to
demonstrate proficiency before someone will grant DD privileges, I'm
sure this is on it!  And competency with the team's DVC/DRC is
integral to this.

Kind regards,
Nicholas