shibboleth-sp2: how to get rid of bug/xmltooling? and future

[Russ Allbery]

Ferenc Wagner <wferi at niif.hu> writes:

> I'm left with a question massaging the SP package: as the fix included
> in bug/xmltooling isn't needed for XMLTooling-C version 1.1, what's the
> best way to get rid of it?  I reverted the single patch in that branch
> and then merged it into master, which worked, but maybe it isn't the
> best solution.  Shall I just push it, or is there a preferred way?

You do that first, and then delete the branch with:

    git branch -d bug/xmltooling
    git push :bug/xmltooling

The final merge makes sure that there aren't any other lingering changes.

> I noticed (after some hours banging my head into the wall) that you
> deleted the obsolete bug branches from the xmltooling and opensaml2
> repos, I guess something similar would be the best here, too.

Yup.

> (By the way, how do you notice when a remote branch is deleted?  git
> pull did not inform me any way, only push insisted it was a new
> branch...)

git remote prune

> That change included I could build the whole stack.  Thank you again for
> doing the merge, you did a perfect job!  Now what should we do?  I'd
> push for some Etch backports now.  We've got a public repository (deb
> http://apt.niif.hu/debian [sid|etch-backports] main) which also contains
> the UNRELEASED 2.1 packages btw.  Should we just use that (it also
> carries some unrelated packages we use internally) or setup something
> else?

Well, only the 2.0 packages are eligible for backports.org, but if it
would be useful to upload a backport of what's currently in testing to
backports.org, I'm willing to do that.  I'd prefer if someone else could
do the merge into the etch branch and the testing, since I don't have an
etch system to use easily for testing.

If you specifically want 2.1, it's probably best to stick with your
existing repositories for the time being, until after the lenny release.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>