profile
viewpoint
Robin Lambertz roblabla @Seed-Up France, FR

PrismarineJS/mineflayer 1392

Create Minecraft bots with a powerful, stable, and high level JavaScript API.

reswitched/libtransistor 194

Open source toolchain for Switch development

MegatonHammer/megaton-hammer 50

The only tool you'll need to hit a Rusty Switch

PrismarineJS/pocket-minecraft-protocol 30

[En][de]code Minecraft packets

ProtoDef-io/node-protodef 20

Describe your protocol, and read it with ease.

h1k421/steam_controller_custom_firmware 10

A custom firmware for the Steam Controller in Rust

backupbrew/switchbrew 7

A backup of switchbrew. Click the website to go to generator ->

lpc-rs/lpc-pac 6

Peripheral Access Crates for LPC microcontrollers

jam1garner/binrw 4

A Rust crate for helping parse and rebuild binary data using ✨macro magic✨.

reswitched/reswitched.team 4

The official website of team ReSwitched!

PR opened rust-embedded/wg

Update MSRV policy

This PR updates our MSRV policy in line with RFC #523.

+22 -53

0 comment

2 changed files

pr created time in 40 minutes

create barnchrust-embedded/wg

branch : new-msrv

created branch time in 41 minutes

PR closed rust-embedded/wg

[RFC] Minimum Supported Rust Version Revisit

Rendered RFC.

Marked as a draft, as not all fields of the RFC have been completed, but the major points are all there.

+105 -0

8 comments

1 changed file

jamesmunns

pr closed time in 3 days

pull request commentrust-embedded/wg

[RFC] Minimum Supported Rust Version Revisit

Closing in favor of #523. Thanks all!

jamesmunns

comment created time in 3 days

delete branch rust-embedded/wg

delete branch : new-msrv

delete time in 3 days

PR merged rust-embedded/wg

[RFC] Alternative new MSRV policy decision-accepted

This RFC is an alternative to #449, as discussed in this week's meeting (logs). It proposes essentially removing our MSRV policy; the new requirement would be "build on current stable Rust".

I would specifically like to solicit feedback from anyone who benefits from our current MSRV policy (generally old Rust versions, at the least no newer than stable-3, specifically documented and tested against, and updated infrequently). At the moment I'm only directly aware of one use-case for a custom target which requires a custom rustc/llvm build. It would be really useful to hear from people who for whatever reason need to use an older Rust version, and to understand a bit more about why they need that and how this change might affect them.

Rendered

+132 -0

4 comments

1 changed file

adamgreig

pr closed time in 3 days

push eventrust-embedded/wg

Adam Greig

commit sha 12d2447ed571b5da9425a71d6c2fb28230ee88cf

Add proposed new MSRV policy

view details

bors[bot]

commit sha 28c9817691d51ecc57796a8e7844210535597cb2

Merge #523 523: [RFC] Alternative new MSRV policy r=therealprof a=adamgreig This RFC is an alternative to #449, as discussed in this week's meeting ([logs](https://freenode.logbot.info/rust-embedded/20201110#c5777770)). It proposes essentially removing our MSRV policy; the new requirement would be "build on current stable Rust". I would specifically like to solicit feedback from anyone who benefits from our current MSRV policy (generally old Rust versions, at the least no newer than stable-3, specifically documented and tested against, and updated infrequently). At the moment I'm only directly aware of one use-case for a custom target which requires a custom rustc/llvm build. It would be really useful to hear from people who for whatever reason need to use an older Rust version, and to understand a bit more about why they need that and how this change might affect them. [Rendered](https://github.com/rust-embedded/wg/blob/new-msrv/rfcs/0523-msrv-2020.md) Co-authored-by: Adam Greig <adam@adamgreig.com>

view details

push time in 3 days

pull request commentrust-embedded/wg

[RFC] Alternative new MSRV policy

Build succeeded:

adamgreig

comment created time in 3 days

push eventrust-embedded/wg

Adam Greig

commit sha 12d2447ed571b5da9425a71d6c2fb28230ee88cf

Add proposed new MSRV policy

view details

bors[bot]

commit sha 28c9817691d51ecc57796a8e7844210535597cb2

Merge #523 523: [RFC] Alternative new MSRV policy r=therealprof a=adamgreig This RFC is an alternative to #449, as discussed in this week's meeting ([logs](https://freenode.logbot.info/rust-embedded/20201110#c5777770)). It proposes essentially removing our MSRV policy; the new requirement would be "build on current stable Rust". I would specifically like to solicit feedback from anyone who benefits from our current MSRV policy (generally old Rust versions, at the least no newer than stable-3, specifically documented and tested against, and updated infrequently). At the moment I'm only directly aware of one use-case for a custom target which requires a custom rustc/llvm build. It would be really useful to hear from people who for whatever reason need to use an older Rust version, and to understand a bit more about why they need that and how this change might affect them. [Rendered](https://github.com/rust-embedded/wg/blob/new-msrv/rfcs/0523-msrv-2020.md) Co-authored-by: Adam Greig <adam@adamgreig.com>

view details

push time in 3 days

delete branch rust-embedded/wg

delete branch : staging.tmp

delete time in 3 days

push eventrust-embedded/wg

Adam Greig

commit sha 12d2447ed571b5da9425a71d6c2fb28230ee88cf

Add proposed new MSRV policy

view details

bors[bot]

commit sha 775fc0246e84ea6a218eca572d2d168b2cb120f2

[ci skip][skip ci][skip netlify] -bors-staging-tmp-523

view details

push time in 3 days

create barnchrust-embedded/wg

branch : staging.tmp

created branch time in 3 days

pull request commentrust-embedded/wg

[RFC] Alternative new MSRV policy

I just noticed we were missing the labels to actually block the merge until a decision has been made. 😅

I don't think we should deviate from our rules and just go ahead and merge this now.

bors r+

adamgreig

comment created time in 3 days

pull request commentrust-embedded/wg

[RFC] Alternative new MSRV policy

As a note:

The requirements for voting majority are:

  • 10/20 approvals before 2020-11-21 (not met)
  • 7/20 approvals between 2020-11-21 and 2020-12-05 (met)
  • 2/20 approvals after 2020-12-05

So, as of yesterday, we are "clear" to approve this RFC. @adamgreig do you want to leave this open until the next meeting to give a "last call"? Or should we go ahead and merge?

adamgreig

comment created time in 3 days

Pull request review commentrust-embedded/wg

[RFC] Alternative new MSRV policy

+- Feature Name: msrv-2020+- Start Date: 2020-11-14+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary+[summary]: #summary++This RFC proposes an update to the [current MSRV policy], and is an+alternative to the earlier proposal [#449]. Some of the RFC text is copied+from that earlier proposal.++This proposal suggests a significantly reduced MSRV guarantee: all WG crates+must build on the _latest stable Rust release_ at all times, and it is+recommended that their main branches are checked to always build on stable via+CI on both pull requests and regularly scheduled CI runs.++[current MSRV policy]: https://github.com/rust-embedded/wg/blob/8eb6488fdb16e92e70b074acc2fcf249b3edc70b/ops/msrv.md+[#449]: https://github.com/rust-embedded/wg/pull/449++# Motivation+[motivation]: #motivation++<!-- Why are we doing this? What use cases does it support? What is the expected outcome? -->++As part of the push to take [foundational crates to 1.0] releases, it has+become necessary to be more exact on our guarantees to support versions of the+Rust compiler. This discussion [has been contentious] in the past, sparking+significant discussions in many meetings.++In particular, it has been necessary to balance the (somewhat opposed) concerns of:++1. Some users may find themselves stuck on old versions of the compiler, due to company restrictions, slow moving distribution/package managers, or regulatory concerns.+2. We maintain these crates on a volunteer basis, and our time is limited to focus on maintenance++Our current MSRV policy has been found to have significant flaws around how+dependencies are managed. Since many WG crates depend on non-WG crates, we+cannot control the MSRV policy of those dependencies without investing+additional effort to vendor or fork those crates. Consequently, a non-breaking+update to a dependency might violate a published crate's MSRV.++So far, the WG has received very little feedback from any users who rely on the+relatively old MSRV, and so most of their use cases have been hypothetical.

I want to agree with @adamgreig here, as someone working on "Sealed Rust", I don't think it makes sense to offer LTS as an open source group, but rather if there is desire for an LTS version tied to a specific (qualified) Rust release, for there to be a separate effort on that once the demand materializes.

For these libraries to be useful for safety critical applications, they would need to be qualified anyway, so the open source, rapidly iterating version would not be useful as-is anyway.

adamgreig

comment created time in 3 days

created repositoryeleboucher/raml2docusaurus

created time in 3 days

startedenocom/gopher-reading-list

started time in 3 days

startedAlikhll/golang-developer-roadmap

started time in 3 days

startedtmrts/go-patterns

started time in 3 days

startedbregman-arie/devops-resources

started time in 4 days

Pull request review commentrust-embedded/wg

[RFC] Alternative new MSRV policy

+- Feature Name: msrv-2020+- Start Date: 2020-11-14+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary+[summary]: #summary++This RFC proposes an update to the [current MSRV policy], and is an+alternative to the earlier proposal [#449]. Some of the RFC text is copied+from that earlier proposal.++This proposal suggests a significantly reduced MSRV guarantee: all WG crates+must build on the _latest stable Rust release_ at all times, and it is+recommended that their main branches are checked to always build on stable via+CI on both pull requests and regularly scheduled CI runs.++[current MSRV policy]: https://github.com/rust-embedded/wg/blob/8eb6488fdb16e92e70b074acc2fcf249b3edc70b/ops/msrv.md+[#449]: https://github.com/rust-embedded/wg/pull/449++# Motivation+[motivation]: #motivation++<!-- Why are we doing this? What use cases does it support? What is the expected outcome? -->++As part of the push to take [foundational crates to 1.0] releases, it has+become necessary to be more exact on our guarantees to support versions of the+Rust compiler. This discussion [has been contentious] in the past, sparking+significant discussions in many meetings.++In particular, it has been necessary to balance the (somewhat opposed) concerns of:++1. Some users may find themselves stuck on old versions of the compiler, due to company restrictions, slow moving distribution/package managers, or regulatory concerns.+2. We maintain these crates on a volunteer basis, and our time is limited to focus on maintenance++Our current MSRV policy has been found to have significant flaws around how+dependencies are managed. Since many WG crates depend on non-WG crates, we+cannot control the MSRV policy of those dependencies without investing+additional effort to vendor or fork those crates. Consequently, a non-breaking+update to a dependency might violate a published crate's MSRV.++So far, the WG has received very little feedback from any users who rely on the+relatively old MSRV, and so most of their use cases have been hypothetical.

We can certainly review the policy in the future, especially if things seem to have settled down further. Sealed Rust is sort of its own thing I think; it would be a commercial offering with commercial support for its MSRV and library versions, so we might not expect to support it as a volunteer-run WG. Or, we might, if it's useful, or perhaps a commercial organisation could help maintain WG support.

Even 1.0 crates would have the same issue with dependencies - it's not generally considered a semver-breaking change to require a new stable feature, so (all hypothetical) cortex-m 1.0 could rely on some bitfields 1.0 and have an MSRV of 1.48, then bitfields 1.0.1 comes out with an MSRV of 1.50 -- what does cortex-m do? In this policy, it just now has an MSRV of 1.50. In other policies we either have to pin bitfields==1.0.0 and force users to deal with the issues, or we'd have to release cortex-m 2.0 just to increase our MSRV, which isn't great either. Or, we forbid using any dependencies not controlled by the WG (or vendor them all ourselves). I think the problem is basically no different with 1.0 crates as with any other version.

adamgreig

comment created time in 4 days

Pull request review commentrust-embedded/wg

[RFC] Alternative new MSRV policy

+- Feature Name: msrv-2020+- Start Date: 2020-11-14+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary+[summary]: #summary++This RFC proposes an update to the [current MSRV policy], and is an+alternative to the earlier proposal [#449]. Some of the RFC text is copied+from that earlier proposal.++This proposal suggests a significantly reduced MSRV guarantee: all WG crates+must build on the _latest stable Rust release_ at all times, and it is+recommended that their main branches are checked to always build on stable via+CI on both pull requests and regularly scheduled CI runs.++[current MSRV policy]: https://github.com/rust-embedded/wg/blob/8eb6488fdb16e92e70b074acc2fcf249b3edc70b/ops/msrv.md+[#449]: https://github.com/rust-embedded/wg/pull/449++# Motivation+[motivation]: #motivation++<!-- Why are we doing this? What use cases does it support? What is the expected outcome? -->++As part of the push to take [foundational crates to 1.0] releases, it has+become necessary to be more exact on our guarantees to support versions of the+Rust compiler. This discussion [has been contentious] in the past, sparking+significant discussions in many meetings.++In particular, it has been necessary to balance the (somewhat opposed) concerns of:++1. Some users may find themselves stuck on old versions of the compiler, due to company restrictions, slow moving distribution/package managers, or regulatory concerns.+2. We maintain these crates on a volunteer basis, and our time is limited to focus on maintenance++Our current MSRV policy has been found to have significant flaws around how+dependencies are managed. Since many WG crates depend on non-WG crates, we+cannot control the MSRV policy of those dependencies without investing+additional effort to vendor or fork those crates. Consequently, a non-breaking+update to a dependency might violate a published crate's MSRV.++So far, the WG has received very little feedback from any users who rely on the+relatively old MSRV, and so most of their use cases have been hypothetical.

I take this lack of feedback as a temporary situation caused by the immaturity of the current ecosystem, but l expect this will change in the context of something like Sealed Rust where the version might be frozen for years.

Is it commonly agreed that the policy will change once such a situation is close to becoming reality?

Similarly, if a create becomes 1.0 shouldn't there an expectation that the msrv to be kept the same for all 1.x versions?

adamgreig

comment created time in 4 days

created tagroblabla/ghidra-ci

tag2020-11-25

created time in 4 days

release roblabla/ghidra-ci

2020-11-25

released time in 4 days

issue commentrust-embedded/wg

Panic handler binary size bloat

Is there a solution for this now that RFC-2070 has been closed?

japaric

comment created time in 5 days

delete branch rust-embedded/wg

delete branch : 2020-11-24

delete time in 5 days

PR merged rust-embedded/wg

Add minutes for 2020-11-24
+136 -0

1 comment

1 changed file

adamgreig

pr closed time in 5 days

push eventrust-embedded/wg

Adam Greig

commit sha 4e140323632588cc2b45e5e010c1d08e6911250e

Add minutes for 2020-11-24

view details

bors[bot]

commit sha 7156cf18df186b529f9d33950334866229183235

Merge #525 525: Add minutes for 2020-11-24 r=jonas-schievink a=adamgreig Co-authored-by: Adam Greig <adam@adamgreig.com>

view details

push time in 5 days

pull request commentrust-embedded/wg

Add minutes for 2020-11-24

Build succeeded:

adamgreig

comment created time in 5 days

delete branch rust-embedded/wg

delete branch : staging.tmp

delete time in 5 days

more