Justus Winter, le Mon 07 Apr 2014 00:26:29 +0200, a écrit : > > The discussion about it with Roland was unfortunately not finished. > > Please enlighten me. I wasn't around when this was discussed,
Well, I wasn't really into the discussion either actually. Pochu did the work. See his mails called like "Add a file_exec_file_name RPC" around Wed, 26 May 2010. > > > I'd also like to see the dde stuff from the incubator repository > > > merged upstream. > > > > For this one, I'd like to avoid having to let userland processes disable > > interrupts, since this brings IRQ sharing issues. > > Why does that prevent the merge? Because that's a quite important incompatible detail in the behavior of the introduced gnumach IRQ RPC. We could perhaps have a look at having a backward-compatibility way, so we can just commit what we have, and change it later on, it's a matter of having a look at it. > > You can commit the dde-related changes in the incubator at the same > > time, both will be pulled at the same time in Debian updates, for > > instance. > > How exactly is it that it is pulled in the Debian updates? Manually > by you, I presume? Just the same way as pulling the main branch. There's a README file in the README branch of the repository. > This has caused me so much pain. And I imagine it is even worse for > new developers. I fully understand all that, it's not fun for me either, and I'd really love to find the time to fix all that. But for now apparently only I have taken the time to dive into Zheng Da's work on DDE, so it doesn't help. We could as well just commit what is there since it's relatively split appart in the source, so it at least doesn't put ugly hacks into other directories. But it really needs some polishing in the end. As for the two other stuff in the Debian hurd package (random, procfs), yes it is a ugly hack, and I'd rather avoid it. It was just a way to get working /dev/random and /proc so people can ran a debian system at all. Of course we should think about just merging them into the main repository, or build them another way, etc. I for myself have never found the time to even just think about it. I end up spending my time mostly fixing & pushing more-or-less-baked patches to Debian packages, so people at least get to try them, but the polishing+submitting work is much more work, and if nobody gives help there, well things can only go slowly for sure. There's a question of priority. For instance, should have I spent my time the other day on DDE / exec_filename / pushing some glibc patches upstream, or on fixing the pthread_condattr_setclock() so glib2.0 can continue working at all? Maybe I should just not do this kind of ugly pushing, so Debian doesn't get them, and thus people would have to really push their changes in properly, and not be happy with just seeing them applied to Debian. In the end, I'd essentially say "Patch Thankfully Welcome", like they do so often on the cygwin mailing list. Of course, that means baked patches, which is quite some work, but the Hurd project is no exception to this requirement. If some discussion died just because a patch was not reviewed, then it's a matter of reviving it. I happen to have dozens of mails in my hurd inbox, I've just never found the time to revive their discussion. If nobody else helps on that, it'll continue getting dust. Put another way, please people just dive into patches, check why they are not upstream (just ask if it's not written in there), and have a look at how to fix that. I don't think there is anything strongly blocking anywhere, it's just a matter of doing things, so that things get done... Samuel
