You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -65,7 +74,7 @@ Open a pull request against the main
65
74
repo.
66
75
67
76
> **Note**
68
-
> It is recommended to run [pre-commit script](precommit.sh) from the root of
77
+
> It is recommended to run [pre-commit script](scripts/precommit.sh) from the root of
69
78
the repo to catch any issues locally.
70
79
71
80
### How to Receive Comments
@@ -126,7 +135,7 @@ For a deeper discussion, see:
126
135
127
136
Currently, the Opentelemetry Rust SDK has two ways to handle errors. In the situation where errors are not allowed to return. One should call global error handler to process the errors. Otherwise, one should return the errors.
128
137
129
-
The Opentelemetry Rust SDK comes with an error type `openetelemetry::Error`. For different function, one error has been defined. All error returned by trace module MUST be wrapped in `opentelemetry::trace::TraceError`. All errors returned by metrics module MUST be wrapped in `opentelemetry::metrics::MetricsError`.
138
+
The Opentelemetry Rust SDK comes with an error type `opentelemetry::Error`. For different function, one error has been defined. All error returned by trace module MUST be wrapped in `opentelemetry::trace::TraceError`. All errors returned by metrics module MUST be wrapped in `opentelemetry::metrics::MetricsError`. All errors returned by logs module MUST be wrapped in `opentelemetry::logs::LogsError`.
130
139
131
140
For users that want to implement their own exporters. It's RECOMMENDED to wrap all errors from the exporter into a crate-level error type, and implement `ExporterError` trait.
132
141
@@ -137,6 +146,28 @@ OpenTelemetry supports multiple ways to configure the API, SDK and other compone
137
146
- Environment variables
138
147
- Compiling time configurations provided in the source code
139
148
149
+
### Experimental/Unstable features
150
+
151
+
Use `otel_unstable` feature flag for implementation of specification with [experimental](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.27.0/specification/document-status.md) status. This approach ensures clear demarcation and safe integration of new or evolving features. Utilize the following structure:
152
+
153
+
```rust
154
+
#[cfg(feature ="otel_unstable")]
155
+
{
156
+
// Your feature implementation
157
+
}
158
+
```
159
+
160
+
It's important to regularly review and remove the `otel_unstable` flag from the code once the feature becomes stable. This cleanup process is crucial to maintain the overall code quality and to ensure that stable features are accurately reflected in the main build.
161
+
162
+
### Optional features
163
+
164
+
The potential features include:
165
+
166
+
- Stable and non-experimental features that compliant to specification, and have a feature flag to minimize compilation size. Example: feature flags for signals (like `logs`, `traces`, `metrics`) and runtimes (`rt-tokio`, `rt-tokio-current-thread`, `rt-async-std`).
167
+
- Stable and non-experimental features, although not part of the specification, are crucial for enhancing the tracing/log crate's functionality or boosting performance. These features are also subject to discussion and approval by the OpenTelemetry Rust Maintainers. An example of such a feature is `logs_level_enabled`.
168
+
169
+
All such features should adhere to naming convention `<signal>_<feature_name>`
170
+
140
171
## Style Guide
141
172
142
173
- Run `cargo clippy --all` - this will catch common mistakes and improve
@@ -152,37 +183,6 @@ projects in this workspace.
152
183
- Run `cargo bench` - this will run benchmarks to show performance
153
184
regressions
154
185
155
-
## Approvers and Maintainers
156
-
157
-
For GitHub groups see the [code owners](CODEOWNERS) file.
0 commit comments