IIRC OpenTracing Bridge for Python has targeted 9/30, please help to double check.

In the Python SIG meeting of 2019-08-29 with @tedsuo we said that we can't promise anything for the bridges yet because they requirements for them are underspecified. I think the remaining goals are ambitious enough (considering e.g. the current state of the context propagation spec discussion).

I don't know that we need the OpenTracing bridge for the alpha release, and it's unlikely that we'd get the OC bridge done by then. If it looks like we'll get it out in time we can update the date, here or in another PR.

is it worth covering propagation/formatters supported? We have B3 header support now, and I believe @a-feld is working on tracestate.

That's why I think that the bridges are underspecified. A minimal bridge IMHO only needs to support instrumenting code, i.e. is completely independent of concrete propagators/formatters. But of course, a more complete compatibility would also imply support for all propagators and exporters that OC supports, including OC's own protocol (100% compat would even need to support plugging existing OC exporters into opentelemetry-python, but I don't think we are aiming for that). Which reminds me that the OC bridge will be somewhat trickier than the OT bridge because since there is no API layer, we will probably need to occupy the same package names that OC does to support migration without source modification?

These topics mostly come from @tedsuo's release doc: https://docs.google.com/spreadsheets/d/1FHt3uJgQWN-UWbgV4uMIPUr36JiJCfZ7ryQbHfurjKA/edit#gid=0. There's a checklist section at the bottom that includes the Jaeger and Prometheus exporters, but I didn't include them here. If we want to commit to including them in the release we can add them.

I didn't include either bridge, but we may want to include at least the OpenTracing bridge here too and leave OC for a later release.

We could mention the pip install PKG@git+https://github.com/open-telemetry/opentelemetry-python.git@COMMIT_OR_BRANCH_OR_TAG#egg=PKG&subdirectory=PKG option too, this way pip does the git clone for you.

I thought about adding this, but there's a lot of benefit to keeping the readme short and... readable. Most people won't need this -- I think it's fine to leave other installation options as an exercise for the reader.

I agree that keeping readme short and readable is a higher priority.
Maybe later we could explore similar thing here https://github.com/census-instrumentation/opencensus-python/pull/549/files.

Why do we recommend the editable install?

Only because we haven't pushed anything to PyPI yet. I don't have a strong opinion on this vs. python setup.py install, but it looks like there are a few good reasons to prefer pip here.

In the Python SIG meeting of 2019-08-29 with @tedsuo we said that we can't promise anything for the bridges yet because they requirements for them are underspecified. I think the remaining goals are ambitious enough (considering e.g. the current state of the context propagation spec discussion).

That's why I think that the bridges are underspecified. A minimal bridge IMHO only needs to support instrumenting code, i.e. is completely independent of concrete propagators/formatters. But of course, a more complete compatibility would also imply support for all propagators and exporters that OC supports, including OC's own protocol (100% compat would even need to support plugging existing OC exporters into opentelemetry-python, but I don't think we are aiming for that). Which reminds me that the OC bridge will be somewhat trickier than the OT bridge because since there is no API layer, we will probably need to occupy the same package names that OC does to support migration without source modification?