Like Bug #36074, this is an experiment in using Bugzilla as a shared to-do list. Let's try tracking things we want fixed in dbus-1.5 here.
* Add blocking bugs to this one if there's a patch you think is
ready for review and small enough for 1.4, but you can't review it
* Add blocking bugs to this one if there's a patch, you've reviewed it,
and you think it needs a small amount of work
* If you've reviewed a patch and it's good, just commit it instead :-)
* Remove blocking bugs if the patch needs significant changes (whitespace,
coding style and other small fixes don't count) or is controversial
- Bug #33336, Bug #33342, Bug #23194, Bug #33337 (in that order):
improved fd handling, and eventually epoll
- Bug #34393 (could possibly even go in 1.4): locking violations at limits
- Bug #14512: build-system
- Bug #29881: easy cleanup
- Bug #33128: easy cleanup
- Bug #34570: end-to-end integration tests not relying on embedding extra goo
in the library
- Bug #32827: .pc file improvements
- Bug #34040: Stats interface (with or without Alban's additions)
Other people's wishlists:
- Bug #34869 (David): ObjectManager (nearly finished)
- Bug #35230 (Lennart): exec transport
- Bug #34526 (Scott, Lennart): Upstart service-activation and potentially
changes to how systemd activates services
- Bug #35232: document systemd transport in the spec
- Bug #35230: add new exec transport on Unix
- Bug #40409: Natively read systemd unit directories to find actvitable services
(In reply to comment #2)
> Lennart's wishlist:
> - Bug #35232: document systemd transport in the spec
> - Bug #35230: add new exec transport on Unix
> - Bug #40409: Natively read systemd unit directories to find actvitable services
- Bug #45520: Introduce --nopidfile
OK, status report. I'm in the process of releasing D-Bus 1.4.18 and 1.5.10. I very much hope we're heading for 1.6, but as ever, I can't maintain D-Bus on my own, so please help!
Bug #14005: documentation fixes - just needs review?
Bug #35230: unixexec transport - reviewed, some implementation fixes needed
Bug #39549: public API for syntax validation - from the department of "make life less hard for bindings"
Bug #39196, Bug #39197: make dbus-launch not suck - need review from someone who understands how dbus-launch works/fits into distros, I think (Colin? Thiago? Lennart?)
Bug #33840: making the build system simpler
Bug #33870: making libdbus internals simpler/more obviously correct
Bug #34671: --enable-maintainer-mode should be on by default,
without it also enabling stuff that's not desirable in a
Taken off the list
Bug #34526, Upstart activation support: unless an Upstart developer "drives" this, justifies design decisions and provides regression tests, it's not likely to happen
Bug #37095, remaining part is "say not to use '/' as entry point" explicitly - easy but needs writing
Major/feature'y things, should land before 1.6:
Bug #37920 - make authentication and authorization decisions earlier so clients can distinguish between lack of auth, and successful auth followed by session end (mostly reviewed, I only appended some "fix stuff" patches)
Bug #38201 - default address semantics: there is discussion there but no review, someone please confirm whether my reasoning and patches are right so we can sort this out?
Bug #39196 - add dbus-run-session so we don't keep abusing dbus-launch
Bug #39197 - make dbus-launch not shoot you in the foot
and Lennart will want Bug #40409 to be on this list, but I've reviewed it, so the ball is in his court now.
Minor, could be fixed in a stable branch IMO:
Bug #33973 - work around Windows' DLL export/import semantics
Bug #34671 - I'm sick of maintainer mode having non-automake consequences
Bug #47237 - unable to test cmake builds on Linux
Bug #47239 - linking to libpthread only works by coincidence
(In reply to comment #5)
> Bug #37920 - make authentication and authorization decisions earlier so clients
> can distinguish between lack of auth, and successful auth followed by session
> end (mostly reviewed, I only appended some "fix stuff" patches)
Sorry, that should say Bug #39720.
Closing this, it doesn't seem to have particularly succeeded in its goal of "get my patches reviewed within a finite time".