Re: Release process rolling new releases

2014-11-19 Thread Samuel Thibault
Justus Winter, le Mon 17 Nov 2014 16:30:18 +0100, a écrit :
 It has now been 2.5 months since I posted that startup patch series,
 and 2 months since I suggested rolling new releases.
 
 I'm annoyed.

I understand this feeling.  I'm still waiting (since several years)
for some patch series to get reviewed by qemu maintainers, and one
patch to get at last accepted in linux' input layer.  I'm quite sad I'm
now in the blocker position, mostly due to having still hundreds of
important mails to process in my mbox, and thus having to delay what
is not strictly for tomorrow or next week...  And I prioritized
uploading your work on libdiskfs threads so people can benefit from it,
rather than reviewing the startup patch series.

I'm however wondering: I don't see much reviewing being done apart
from mine.  It would help if some people could spend time on reviewing
patches.  I'm not saying taking responsibility for the commit step or
anything, but just proofreading the source code.  That is what takes
time before committing, and thus what prevents me from giving an ack on
something for which I already agree on the principle...

Samuel



Re: Release process rolling new releases

2014-11-19 Thread David Michael
On Wed, Nov 19, 2014 at 6:59 PM, Samuel Thibault
samuel.thiba...@gnu.org wrote:
 Justus Winter, le Mon 17 Nov 2014 16:30:18 +0100, a écrit :
 It has now been 2.5 months since I posted that startup patch series,
 and 2 months since I suggested rolling new releases.

 I'm annoyed.

 I understand this feeling.  I'm still waiting (since several years)
 for some patch series to get reviewed by qemu maintainers, and one
 patch to get at last accepted in linux' input layer.  I'm quite sad I'm
 now in the blocker position, mostly due to having still hundreds of
 important mails to process in my mbox, and thus having to delay what
 is not strictly for tomorrow or next week...  And I prioritized
 uploading your work on libdiskfs threads so people can benefit from it,
 rather than reviewing the startup patch series.

 I'm however wondering: I don't see much reviewing being done apart
 from mine.  It would help if some people could spend time on reviewing
 patches.  I'm not saying taking responsibility for the commit step or
 anything, but just proofreading the source code.  That is what takes
 time before committing, and thus what prevents me from giving an ack on
 something for which I already agree on the principle...

I might not be able to do a very thorough review, but for what it's
worth, I've been using the startup patches for a while now without any
problems.  The only issue was that /etc/hurd/runsystem.hurd didn't get
installed.  I tacked the following onto patch #4 in the series to try
it.

David


--- a/daemons/Makefile
+++ b/daemons/Makefile
@@ -32,6 +32,7 @@
 getty-LDLIBS = -lutil

 INSTALL-mail.local-ops = -o root -m 4755
+INSTALL-runsystem.hurd-ops = -m 0755

 include ../Makeconf

@@ -44,3 +45,9 @@
 runttys-LDLIBS = -lutil

 runsystem: runsystem.sh
+
+install: $(sysconfdir)/hurd/runsystem.hurd
+$(sysconfdir)/hurd/runsystem.hurd: runsystem.hurd | $(sysconfdir)/hurd
+$(INSTALL_PROGRAM) $(INSTALL-runsystem.hurd-ops) $ $@
+$(sysconfdir)/hurd: | $(sysconfdir)
+mkdir -p $@