Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

[Samuel Thibault]

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