From 12c341b917921eb631026ec44a284c4d884e5de6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Wed, 6 Mar 2013 21:52:20 +0100
Subject: IRC.

---
 open_issues/packaging_libpthread.mdwn | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

(limited to 'open_issues/packaging_libpthread.mdwn')

diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
index 18f124b4..171dc7a0 100644
--- a/open_issues/packaging_libpthread.mdwn
+++ b/open_issues/packaging_libpthread.mdwn
@@ -155,6 +155,30 @@ cherry-picked.
       upstream
 
 
+## IRC, OFTC, #debian-hurd, 2013-02-08
+
+    <tschwinge> I also have it on my (never-ending) agenda to add libpthread to
+      the tschwinge/Roger_Whittaker branch and/or propose it be added upstream
+      (as a Git submodule?).
+    <pinotree> imho a git submodule could be a solution, if glibc people would
+      accept it
+    <pinotree> if so, libpthread.git would need proper glibc/x.y branches to
+      follow glibc
+    <tschwinge> Yep.
+    <tschwinge> I though that would be the least invasive approach for glibc
+      upstream -- and quite convenient for us, too.
+    <pinotree> after all, git submodules don't track branches, but point to
+      specific commits, no?
+    <tschwinge> Correct.
+    <tschwinge> So we can do locally/in Debian whatever we want, and every once
+      in a while update the upstream glibc commit ID for libpthread.
+    <pinotree> so we could update the git submodule references in glibc when
+      we've tested enough libpthread changes
+    <tschwinge> Just like when committing patches upstream, just without
+      pestering them with all the patches/commits.
+    <tschwinge> Yep.
+
+
 # IRC, freenode, #hurd, 2012-11-16
 
     <pinotree> *** $(common-objpfx)resolv/gai_suspend.o: uses
-- 
cgit v1.2.3