Re: hurd/glibc.git and merging

[Samuel Thibault]

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