Bug#794222: Missing patch
On Mon, Aug 17, 2015 at 7:06 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>> So this is IMO, the wrong thing to do. You should push the patch into
>>> upstream 2.19 stable and rebase instead of keeping the patch in debian
>>> svn. Given the patch is already in upstream master it is OK to commit
>>> to 2.19 stable, and post to libc-stable stating you checked in this
>>> fix. That way debian gets broader testing of the patches we are using
>>> instead of the narrower "just debian" users.
>>
>> If it is fine to push this kind of patch in this branch, I would
>> certainly do that. I also backported for debian patch b0a3c164. Would
>> it be possible to also push it to the branch?
>
> If the patch doesn't change API/ABI, and it was accepted for master,
> then it's perfectly acceptable to push to 2.19 stable branch.
>
> You post your commit email to libc-stable so other maintainers know
> why you're pushing the patch.
>
> You'd post a Subject:[COMMITTED] 2.19: Fix blah blah blah, Body:
> Cherry picked fix for the ppc64le bug X into 2.19.
>
> Following the usual cherry pick process:
> https://sourceware.org/glibc/wiki/GlibcGit#Cherry_Pick_Changes_From_Another_Branch
>
> Then you're done. The 2.19 branch is a rolling stable release from
> which you can rebase your own distro branches, either external (on
> sourceware) or internal (in your own repos in the distro).
Please make sure to merge the ChangeLog and NEWS though, and start a
new 2.19.1 NEWS section if it isn't started. That way if someone wants
to cut a release they can. Though the intent is never to cut a release
and always roll the branches and let distros rebase.
c.
Reply to: