Re: Upstreaming patches

[Justus Winter]

Quoting Samuel Thibault (2014-04-07 01:02:56)
> > 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 I said, for me it was also a matter of visibility and awareness.
If the dde stuff would have been in the main repo, I would have
applied all the cleanups and ipc improvements I've done to every other
Hurd component.  I would have found problems with the clang static
analyzer runs, and I would have found stuff by just doing git grep.

> 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.

Yes please.  I never understood why those are in separate
repositories.

> 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.

Well, the patches are there.  The exec_filename_* series has been
proposed two times, by Emilio in 2010, and then by Jeremie in 2011.
The second posting didn't even receive a single reply.  What else can
one do?

> Of course, that means baked patches, which is quite some work, but
> the Hurd project is no exception to this requirement.

I don't buy it.  I do not believe in getting it right from the
beginning, I believe in incremental refinement.  Also, all software is
crap and the Hurd is unfortunately no exception to this rule.  For
example, the server side rpc handling code did not follow the best
practices described by the 'Mach 3 Server Writer's Guide'.  Sure, it
would have been awesome if everyone got that right from the start, but
they didn't.  And still I'm glad that the code made it into the Hurd
codebase nonetheless, because otherwise there wouldn't be any Hurd
server at all.

> 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.

Yes, it's a matter of manpower, agreed.  But...

> 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...

... I disagree here.  If I start developing for a new project, the
first thing I do is clone the repo and build it.  Doing that for Hurd
results in a broken system.  That surely has the potential to scare
away potential contributors, and I cannot blame them a bit.


I believe that it is essential to reduce every bit of overhead
possible from the development process.  Developing software is hard
enough as it is.  If I (and you, and everyone) needs to burn time and
energy on building the software, needlessly, just because the process
is so rough, then this is detrimental to the project.

Justus