[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC: upstreaming debian/patches/exec_filename_* and the dde stuff
From: |
Justus Winter |
Subject: |
RFC: upstreaming debian/patches/exec_filename_* and the dde stuff |
Date: |
Sun, 06 Apr 2014 19:58:45 +0200 |
User-agent: |
alot/0.3.4 |
Hi,
I'd like to see more of the debian/patches merged, especially the
exec_filename_* series. These patches cover a lot of files, and they
often break and I have to amend them manually. More often than not
the fix is trivial, but it is still a nuisance. I'd also like to see
the dde stuff from the incubator repository merged upstream.
1/ Code that does not live in the Hurd repository receives less
attention. I've been doing a lot of cleanups, static analysis and
performance improvements lately. The dde stuff for example has not
received any of those.
2/ The nice Guix folks surely also want all those goodies, so they
either have to copy those patches, or they miss out. In either way, I
feel like we (Hurd upstream) would have failed them.
3/ I feel that this situation creates an unnecessary drag for the
development. I'm working on protected payloads to improve the object
lookups in the Hurd servers. I've just came up with a patch that
fixes some object lookups in libports. This requires changing the API
of libports. I fixed all the code in the Hurd repository accordingly,
unfortunately the dde stuff breaks if it isn't fixed as well. If it
was living in the same repository, I could fix it up in one commit,
making sure that the change is atomic.
So, is the dde stuff a first class citizen? If so, I believe it
should be merged. If not, may I change the API of, say, libports
freely? May I merge that patch that breaks the dde servers? If not,
why not, and what is the best way to proceed?
Cheers,
Justus
- RFC: upstreaming debian/patches/exec_filename_* and the dde stuff,
Justus Winter <=