RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1
Nicholas D Steeves
nsteeves at gmail.com
Fri May 20 20:30:36 UTC 2016
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
Tagged bpo changelogs will only have one "Rebuild for jessie-backports" entry.
All these entries will somehow be prepended to the changelog in the
Or will the debian/changelog on the jessie-backports branch be
identical to the latest tagged bpo?
>> 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 checkout v4.5.2
git checkout v4.5.2
git stash pop
git tag -a v184.108.40.206 -m "Backport trivial spelling fixes from v4.5.3"
git add -u
At this point, what I found was that if I do a checkout master, and
then do a checkout v220.127.116.11, 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 v18.104.22.168 cce2f0d
Updated tag 'v22.214.171.124' (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,
> 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.
More information about the pkg-multimedia-maintainers