Shared Goals and values

[jacobrosenthal]

This org will attempt to do for silabs what Im seeing happen over at https://github.com/nrf-rs/ and https://github.com/stm32-rs

@chrysn brings up a good point, we should be somewhat aligned.

My interest is in remaining fairly 'upstream' with the concepts coming out of embedded working group, generally by removing shared global register access through ownership, and attempting to utilize from and push upstream to the embedded hal trait pool.

Semver, clean commits, using pr's and having someone else approve them are important code hygene for me.

What else?

[chrysn]

I suggest we shape those ideas into the README of the wg repo I've just checked in to start PRs on that.

I'm with you as far as following embedded-wg best practice.

Semver is something we need to follow, and I'm with you on clean commits. PRs with second opinion are a worthy goal, but we do (and will) have areas that are experimental and unsettled, and need faster movement.

Proposal: gate parts of the HAL by a feature like "unproven". Thus we can start with things that have settled and require peer-reviewed PRs there, and have modules (like Timer on which I'm currently working heavily) that are unstable, which are worked on like a feature branch.

Back once more to semver: That'd allow us to not too quickly churn through 0.x versions (as it's my impression that there is a convention to try to stay compatible from 0.1 to 0.1.1, even though semver itself doesn't perscribe it), and when we reach 1.0 we can still move in unproven/unstable features until we stabilize them.

[jacobrosenthal]

Proposal: gate parts of the HAL by a feature like "unproven". Thus we can start with things that have settled and require peer-reviewed PRs there, and have modules (like Timer on which I'm currently working heavily) that are unstable, which are worked on like a feature branch.

Honestly I would argue people should work longer in feature branches and forks, But theres definitely a point where a feature touches so much outside of itself or is depended on by other features, it needs to be in master and yes I like the unproven model.

Semver is something we need to follow, and I'm with you on clean commits. PRs with second opinion are a worthy goal, but we do (and will) have areas that are experimental and unsettled, and need faster movement.

Agreed. The last thing I want is to be unable to ship stuff because of process. I still think a few hours or a day or something is an allowable 'wait' for a PR just so people can comment and ask questions and understand just to eventually come to consensus on style, otherwise its code fiefdoms. But yes, lack of response should be considered consensus.

Back once more to semver: That'd allow us to not too quickly churn through 0.x versions (as it's my impression that there is a convention to try to stay compatible from 0.1 to 0.1.1, even though semver itself doesn't perscribe it), and when we reach 1.0 we can still move in unproven/unstable features until we stabilize them.

Honestly that convention doesn't matter as much to me, nor does the worrying about lots of major bumps, but I don't really care as long as we can keep moving.

[chrysn]

Honestly I would argue people should work longer in feature branches and forks, But theres definitely a point where a feature touches so much outside of itself or is depended on by other features, it needs to be in master and yes I like the unproven model.

I'm confident we'll find a suitable balance that uses both. With PRs to get approved or (in unproven land) not rejected, parts will be developed in branches anyway.

Things just need to be fully merged for releases, and I'd rather have more of them, thus snapshotting things to be usable by other crates.