Re: Release process rolling new releases
Woohoo! Congratulations to everyone involved! :-) Ludo’.
Re: Release process rolling new releases
Quoting Thomas Schwinge (2015-04-09 09:57:05) Hi! On Wed, 08 Apr 2015 00:35:17 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Quoting Thomas Schwinge (2014-09-23 17:09:30) The (technical) release process is not the problem; that I can do any time. Awesome! Let's make one now. :-) Will do tomorrow morning. Cool! I know the NEWS files have been updated occasionally -- are they up to date now? Yes. Thanks, Justus
Re: Release process rolling new releases
Hi! On Wed, 08 Apr 2015 00:35:17 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Quoting Thomas Schwinge (2014-09-23 17:09:30) The (technical) release process is not the problem; that I can do any time. Awesome! Let's make one now. :-) Will do tomorrow morning. I know the NEWS files have been updated occasionally -- are they up to date now? Grüße, Thomas signature.asc Description: PGP signature
Re: Release process rolling new releases
Quoting Thomas Schwinge (2014-09-23 17:09:30) The (technical) release process is not the problem; that I can do any time. Awesome! Let's make one now. Justus
Hurd development (was: Release process rolling new releases)
Hello :) Quoting Thomas Schwinge (2014-11-22 18:00:06) Justus, believe me, I do understand your frustration. Thank you very much for being insistent, instead of just going away. It has been two months, time to escalate the issue again :) The glibc change is trivial. And even if the change is not applied to the glibc, it only breaks the system shutdown. Furthermore, I believe that we, the Hurd developers, should be entitled to make such a change without the explicit consent of the glibc developers. If this is not the case, then I do not believe that developing the Hurd is very practical, or even possible, given that half of the Hurd system is implemented in the glibc. Yes. I have already started discussing some procedural changes, and will follow up once I'm back home (currently travelling), in early December. I have reimplemented the startup server. The new server does not support the startup protocol over its message port. This change has not made it into the glibc. The shutdown isn't working. Our development process is severely broken. Or noone gives a shit anymore. Or both. I really cannot tell. Justus
Re: Hurd development (was: Release process rolling new releases)
Justus Winter, le Fri 16 Jan 2015 11:42:23 +0100, a écrit : Our development process is severely broken. Or noone gives a shit anymore. Or both. I really cannot tell. Possibly part of the former. Definitely not the latter. Personally, I've been unfortunately stuck with various unexpected issues in the past week. Samuel
Re: Hurd development (was: Release process rolling new releases)
Quoting Samuel Thibault (2015-01-16 11:56:14) Justus Winter, le Fri 16 Jan 2015 11:42:23 +0100, a écrit : I have reimplemented the startup server. The new server does not support the startup protocol over its message port. This change has not made it into the glibc. The shutdown isn't working. AIUI it is working in the Debian libc thanks to the submitted-startup-pid2.diff patch there, and it is working in the tschwinge/Roger_Whittaker branch of our glibc tree, and thus all is missing now is submitting the patch to upstream, or am I missing something? No it is not. I have a new server that implements the startup protocol, and it neither has a fixed PID nor does it speak the startup protocol over its message port. Justus
Re: Hurd development (was: Release process rolling new releases)
Quoting Samuel Thibault (2015-01-16 12:08:07) Justus Winter, le Fri 16 Jan 2015 12:01:26 +0100, a écrit : No it is not. You mean in Debian? Yes. I have a new server that implements the startup protocol, and it neither has a fixed PID nor does it speak the startup protocol over its message port. You mean your recent rewrite of startup in scheme, for which the brownpaper patch in the Debian tree is not enough, but the proper patch in our glibc tree is? Correct. The proper thing to do is to look up `/servers/startup', which Davids patch does. I'm sorry it must be looking like obvious questions for anybody who have been really following the matters lately, but I have not for personal reasons (which are fortunately mostly over), and I hate not having done so, but that's unfortunately what has happened. Well, I haven't really talked too much about that. The short version is, that I split up `startup' into two components. One of those components, `startup-standalone' (for the lack of a better name), supervises the core servers and handles the system shutdown. I bind it to `/servers/startup' for my new bootstrap procedure. Also, don't you have commit access to the debian packaging? I guess that's one of the things we must fix. No I don't have access. Justus
Re: Release process rolling new releases
Quoting Samuel Thibault (2014-11-23 21:11:05) Hello, David Michael, le Wed 19 Nov 2014 19:39:43 -0500, a écrit : 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. Justus, do we need it? I guess it cannot hurt to install it. I have no strong feelings either way. The way I see it is: There is just one Hurd distribution, Debian GNU/Hurd, and it uses sysvinit. If the guix project gets their Hurd port up and running, and I hope they do, then they will be using dmd. I wrote the init daemon and modified the runsystem script merely to get the `proc_set_init_task' patch merged. I don't expect it to be used. Justus
Re: Release process rolling new releases
On Sun, Nov 23, 2014 at 4:01 PM, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Quoting Samuel Thibault (2014-11-23 21:11:05) Hello, David Michael, le Wed 19 Nov 2014 19:39:43 -0500, a écrit : 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. Justus, do we need it? I guess it cannot hurt to install it. I have no strong feelings either way. The way I see it is: There is just one Hurd distribution, Debian GNU/Hurd, and it uses sysvinit. If the guix project gets their Hurd port up and running, and I hope they do, then they will be using dmd. I wrote the init daemon and modified the runsystem script merely to get the `proc_set_init_task' patch merged. I don't expect it to be used. I don't feel very strongly about it either since I'm not using it myself (I switched to dmd), but I'd lean toward installing it by default for upstream Hurd to make things easier for anyone else trying to build their own Hurd system outside the usual distros. The default startup scripts could successfully boot a usable system before this patch set. But if the expectation is that now a separate init system will be installed, I'd be okay with that, too. David
Re: Release process rolling new releases
Hi! Justus, believe me, I do understand your frustration. Thank you very much for being insistent, instead of just going away. On Thu, 20 Nov 2014 14:03:43 +0100, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Either more people have to review the patches, or we need to change the commit policy. I agree. Also, let's just merge the startup patch series. The hairy part of it has been tested in Debian Hurd for a year now. We agree on the principle, and noone took the time or cared enough to disagree with the patch series. A reasonable assertion. The glibc change is trivial. And even if the change is not applied to the glibc, it only breaks the system shutdown. Furthermore, I believe that we, the Hurd developers, should be entitled to make such a change without the explicit consent of the glibc developers. If this is not the case, then I do not believe that developing the Hurd is very practical, or even possible, given that half of the Hurd system is implemented in the glibc. Yes. I have already started discussing some procedural changes, and will follow up once I'm back home (currently travelling), in early December. Grüße, Thomas signature.asc Description: PGP signature
Re: Release process rolling new releases
Quoting Samuel Thibault (2014-11-20 00:59:23) 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 agree. Either more people have to review the patches, or we need to change the commit policy. Also, let's just merge the startup patch series. The hairy part of it has been tested in Debian Hurd for a year now. We agree on the principle, and noone took the time or cared enough to disagree with the patch series. The glibc change is trivial. And even if the change is not applied to the glibc, it only breaks the system shutdown. Furthermore, I believe that we, the Hurd developers, should be entitled to make such a change without the explicit consent of the glibc developers. If this is not the case, then I do not believe that developing the Hurd is very practical, or even possible, given that half of the Hurd system is implemented in the glibc. Justus
Re: Release process rolling new releases
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
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 $@
Re: Release process rolling new releases
Quoting Justus Winter (2014-10-28 22:17:18) Hello :) Quoting Samuel Thibault (2014-10-06 11:30:26) Thomas Schwinge, le Mon 06 Oct 2014 11:22:50 +0200, a écrit : So, anything specific that we should wait for before bundling the next release snapshots? It'd be nice to include the init-startup series after review. (I'm OK with the principle, we need to review the patch, and get the glibc ack from Roland) It has been a month since I posted the change, and two weeks since I pointed Roland to this patch series. I say we don't need his ok, since I didn't break the old way the libc gets a handle to the startup server. Looking up the message port still works (I'd like to change that, but that can wait). The only thing that's changed is the pid. I'm sure Roland is okay with updating the 1 to a 2. 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. Justus
Re: Release process rolling new releases
Hello :) Quoting Samuel Thibault (2014-10-06 11:30:26) Thomas Schwinge, le Mon 06 Oct 2014 11:22:50 +0200, a écrit : So, anything specific that we should wait for before bundling the next release snapshots? It'd be nice to include the init-startup series after review. (I'm OK with the principle, we need to review the patch, and get the glibc ack from Roland) It has been a month since I posted the change, and two weeks since I pointed Roland to this patch series. I say we don't need his ok, since I didn't break the old way the libc gets a handle to the startup server. Looking up the message port still works (I'd like to change that, but that can wait). The only thing that's changed is the pid. I'm sure Roland is okay with updating the 1 to a 2. Justus
Re: Release process rolling new releases
Hi! On Tue, 23 Sep 2014 18:42:00 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: [new releases] I'll propose updates for the NEWS files. Thanks for these! (It's of course fine to directly include updates to those files in any commits whose changes are NEWS-file-worthy.) So, anything specific that we should wait for before bundling the next release snapshots? Or should I just do it at an arbitrary point in time, to highlight the fact that it's just that: a snapshot? ;-) Grüße, Thomas pgph0K8R6yhaC.pgp Description: PGP signature
Re: Release process rolling new releases
Thomas Schwinge, le Mon 06 Oct 2014 11:22:50 +0200, a écrit : So, anything specific that we should wait for before bundling the next release snapshots? It'd be nice to include the init-startup series after review. (I'm OK with the principle, we need to review the patch, and get the glibc ack from Roland) Samuel
Release process rolling new releases
Hi Thomas, hi Samuel :) I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. Thanks, Justus
Re: Release process rolling new releases
Hi! On Tue, 23 Sep 2014 16:19:02 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. The (technical) release process is not the problem; that I can do any time. For me, the question rather is, what constitutes the releases that we publish? Some new, exciting features (including considerable bug fixing, code re-writes, re-factoring, and so on), on the one hand, or regular time-based releases on the other (for example, annually). The former has the process that the new features are added, and then there is a stabilization period where only bug fixes go in, then the release is made, and the latter is basically just a snapshot of the repository at a more or less random date. Due to lack of manpower to maintain a proper release process, I see us more on the side of doing snapshots, which we can do any time we like. Now is a good time, you say? (I'm not disagreeing -- the previous release having been one year ago.) Given this, and with our last Hurd release having been 0.5, what would the next version be? 0.5.1? 0.6? Or, make it obvious that it is just a snapshot, and thus call that GNU Hurd 20140923 or similar? Grüße, Thomas pgpbR8NwZMqCe.pgp Description: PGP signature
Re: Release process rolling new releases
On Tue, Sep 23, 2014 at 05:09:30PM +0200, Thomas Schwinge wrote: For me, the question rather is, what constitutes the releases that we publish? Some new, exciting features (including considerable bug fixing, code re-writes, re-factoring, and so on), on the one hand, or regular time-based releases on the other (for example, annually). The former has the process that the new features are added, and then there is a stabilization period where only bug fixes go in, then the release is made, and the latter is basically just a snapshot of the repository at a more or less random date. Due to lack of manpower to maintain a proper release process, I see us more on the side of doing snapshots, which we can do any time we like. Now is a good time, you say? (I'm not disagreeing -- the previous release having been one year ago.) Given this, and with our last Hurd release having been 0.5, what would the next version be? 0.5.1? 0.6? Or, make it obvious that it is just a snapshot, and thus call that GNU Hurd 20140923 or similar? I suggest time-based releases, using a 0.x scheme (until the major number can be bumped to 1), so a 0.6 release. These would be snapshots of the repositories, and 0.x.y releases would include bug fixes, probably based on demand, for highly annoying bugs. As mentioned, one release every 6-to-12 months should be enough. The goal here is merely to provide specific points in time that others can base their work on (the Nix-based distribution comes to mind). -- Richard Braun
Re: Release process rolling new releases
Quoting Richard Braun (2014-09-23 17:23:49) On Tue, Sep 23, 2014 at 05:09:30PM +0200, Thomas Schwinge wrote: For me, the question rather is, what constitutes the releases that we publish? Some new, exciting features (including considerable bug fixing, code re-writes, re-factoring, and so on), on the one hand, or regular time-based releases on the other (for example, annually). The former has the process that the new features are added, and then there is a stabilization period where only bug fixes go in, then the release is made, and the latter is basically just a snapshot of the repository at a more or less random date. Due to lack of manpower to maintain a proper release process, I see us more on the side of doing snapshots, which we can do any time we like. Now is a good time, you say? (I'm not disagreeing -- the previous release having been one year ago.) Given this, and with our last Hurd release having been 0.5, what would the next version be? 0.5.1? 0.6? Or, make it obvious that it is just a snapshot, and thus call that GNU Hurd 20140923 or similar? I suggest time-based releases, using a 0.x scheme (until the major number can be bumped to 1), so a 0.6 release. These would be snapshots of the repositories, and 0.x.y releases would include bug fixes, probably based on demand, for highly annoying bugs. As mentioned, one release every 6-to-12 months should be enough. The goal here is merely to provide specific points in time that others can base their work on (the Nix-based distribution comes to mind). My thoughts exactly. I'll propose updates for the NEWS files. Justus
Re: Release process rolling new releases
Justus Winter 4win...@informatik.uni-hamburg.de skribis: I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. Excellent initiative! It would be ideal (but maybe I’m asking for too much) if this would come with a libc tarball as well, presumably based on the sv.gnu.org repo rebased on the latest libc released. In the short term that would be helpful for Guix, and in the longer term that would help the project as a whole I think. Thanks, Ludo’.
Re: Release process rolling new releases
I would think that an annual release, or a release every 2 years, coupled with a snapshot every 2 month, would be the best for most people. On Tue, Sep 23, 2014 at 1:15 PM, Ludovic Courtès l...@gnu.org wrote: Justus Winter 4win...@informatik.uni-hamburg.de skribis: I understand you took care of the release process last time. Is this process documented somewhere? I think that we should make another round of releases. In fact, we should make one or two releases each year. At the very least it brings us quite a bit of attention. If it's just a matter of doing this or that, please let me know how I can contribute to this process. Excellent initiative! It would be ideal (but maybe I’m asking for too much) if this would come with a libc tarball as well, presumably based on the sv.gnu.org repo rebased on the latest libc released. In the short term that would be helpful for Guix, and in the longer term that would help the project as a whole I think. Thanks, Ludo’.
