On Mon, Aug 17, 2015 at 7:06 PM, Carlos O'Donell <car...@systemhalted.org> wrote: > On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno <aurel...@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.