Hello, Roland McGrath, le Wed 09 May 2012 13:57:38 -0700, a écrit : > I've looked at a small handful of the branches > and some seem quite trivial to merge.
Yes. > But they are not really merge-ready. Some are completely lacking > ChangeLog entries, and I'd rather have these written by the person who > made the change than do it myself. Some have incomplete ChangeLog > entries (not mentioning every file touched). Usually, no changelog means the branch is still being worked on and not ready for submission. I have had a tour around the branches, added some things here and there, and I believe the following are ready for submission, perhaps missing some changelog bits, but not much: t/IPV6_PKTINFO t/O_CLOEXEC t/SOL_IP t/____longjmp_chk t/accept4 t/bits_socket.h t/catch-signal t/critical-sections t/dl-sysdep.c_SHARED t/dup3 t/fcntl-internal.h t/host-independency t/init-first.c t/ioctl_decode_argument t/itimer-lock t/kernel-features.h_includes t/libc_once t/libc_stack_end t/linkobj t/mach-nanosleep t/missing_includes t/mkdir_root t/mlock t/mmap t/no-hp-timing t/no_hidden t/null-pathname t/opendirat t/pipe2 t/pldd t/posix2008 t/posix_opt.h t/readlinkat t/recvfrom t/sbrk t/select-inputcheck t/setresid t/socket_flags t/socket_server_indexcheck t/strtoul_PLT t/struct_stat t/symlink_dealloc t/sysvshm t/usr t/verify.h tg/dup3-lock And the followings "just" need writing a full ChangeLog t/extern_inline t/sendmsg-SCM_RIGHTS > Probably all are missing proper copyright year updates for the current > protocol (which is to collapse down to a single year range ending in > 2012). That's very probable. > Unless I've been even more remiss than I thought I'd been, some of > these changes were never posted for my review at all. Probably some, yes. I don't think everything that was submitted is there, in particular Pino's last patches. > I guess I was sufficiently remiss for a long time that people could > reasonably have given up, Some of the more involved patches have been submitted, but for that reason some others have not, indeed. > Certainly the easiest thing for me is if each change is turned into > a git branch that is suitable for direct merging into the libc > trunk, or a git-am-friendly posting. > I think we could get through the vast majority, which are simple > cases, with no more than a day of focused work. The result of tg patch on the abovementioned branches should be almost fine already. > Who wants to help? I'm not sure we need to synchronize. We can simply point you at tg branches when they get in a reasonable state. Samuel
