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

Mattia Rizzolo mattia at debian.org
Sat Apr 30 02:42:06 UTC 2016


On Fri, Apr 29, 2016 at 07:55:29PM -0400, Nicholas D Steeves wrote:
> > I see you pushed to the master branch.  This is wrong straigh away.
> > The master branch is used to do the main development of the package, and
> > targets either unstable or experimental.  If you want to keep the
> > backports stuff in a branch (as I think you could very well do), do it
> > in a jessie-backports branch, not master.
> 
> But you said you preferred it to be pushed with just a tag!

yes, but not in master!
A tag is always wanted in any case, with "just a tag" I was meaning a
tag that is not in any branch, try having a look at some package of mine
with a backport (like pbuilder, diffoscope, s3fs-fuse,...), you'll see
that there is a bpo tag, but the commit referenced by that tag is not in
any branch.
But I can easily see how this can be confusing/hard, so a
jessie-backports tag is just a very good way to deal with it! :)

> So you wanted me to detach from the master branch with: git checkout
> master^ before making changes?

git checkout master^ would bring you to whatever is right before master
(what's so special about the second-last commit on master?)
You should make sure that you are on the commit describing the uploaded
package, which not always is what is pointed by master.
So probably here I'd say that you should do `git checkout debian/3.7.2-1`
(or whatever version you are backporting) before doing anything

> And when the next version of the package hits stable I'd git checkout
> master && git checkout master^ ?

erm?  Can't understand what you mean here (1/ "hits stable" is very much
something not real 2/ `git checkout master && git checkout master^`
looks very fishy, what would do that?)

> I'd be happy to take responsibility for my mistake, especially since
> I'd like to learn to to fix it.  According to the following guide I
> should be able to do with with:
> https://www.atlassian.com/git/tutorials/undoing-changes/git-checkout

That would be mostly about undoing a particular change in a file in a
subsequent commit.

My question before was mostly aimed to the others members of the team,
to know whether they like destroying history or not.
In the first case a `git reset --hard 7c8a90` and `git push --force`
(note that this might require more work, as non-fast-forward pushes are
not usually allowed by the remote repos on alioth) should be enough.
In the second, a `git revert a6274ea` will create another commit
reverting the changes done after that commit specified, and pushed so.

Just saying (as I'd like to hear from somebody else), if the first was
done without deleting the tag, such tag would be the way I prefer them
to be when dealing with backports :)

> What tag would you like me to use for the backport?

the tag should be 'debian/$version', so like 'debian/3.7.2-1_bpo8+1'.
`gbp buildpackage` would create it right.

-- 
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/20160430/f0cd3644/attachment.sig>


More information about the pkg-multimedia-maintainers mailing list