ciakval[m] has quit [Quit: Idle timeout reached: 172800s]
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]
jakzale has quit [Write error: Connection reset by peer]
jakzale has joined #rust-embedded
<JasperHarrison[m>
<mameluc[m]> "on a wio-e5 (stm32wle) I get..." <- Same error as everywhere else, and while it sucks that the current impl is wrong, it being broken everywhere means that I may have no clue on the logic behind it's design (the current implementation doesn't match what is described in the reference manuals) it means there's no weird edge case with some of the hardware. Thanks!
<JasperHarrison[m>
* reference manuals),, * but it, * it _also_ it means there's
Darius has quit [Ping timeout: 268 seconds]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
(i'll open the relevant rust-lang/team pr tonight)
<adamgreig[m]>
then I think the only other thing on my list is to discuss the member cleanup we mentioned last week, and the triage issues jannic has noted
<adamgreig[m]>
anyone else have anything to announce first?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Wanted to remind everyone that the RustConf talk proposals are open. Would love to see many embedded talks there.
<adamgreig[m]>
how's your academic miniconf plan going?
<bartmassey[m]>
I've been swamped the last couple weeks and haven't gotten it started. This week for sure.
<adamgreig[m]>
ugh, sounds familiar
<JamesMunns[m]>
Ah, I want to plug the rust society stuff, and that I'll have a session at the unconf for it
<adamgreig[m]>
what part of the unconf, all hands or embedded unconf or other?
<JamesMunns[m]>
adamgreig[m]: I forget exactly where the session is, it's one of the ones that Mara is organizing? I'll hunt it down in a sec
<JamesMunns[m]>
but tl;dr: it seems likely the "Launching Pad" is going to become a persistent "cross cutting concerns" top level team, and the current leading (only) proposal for domain working groups is the potential to set up a "Rust Society", a structure (probably) outside the Rust Project itself, aimed for groups to be able to self-organize
<adamgreig[m]>
is the unconf session about both topics (i.e. new cross-cutting subteams and rust soc / working groups) or more specifically on the former?
<adamgreig[m]>
iirc the proposal and first work is more about rechartering t-lp to be t-ccc?
<JamesMunns[m]>
tbd, IMO it will probably be aimed at both:
<JamesMunns[m]>
* Discussion from groups that might want to be initial society chapters
<JamesMunns[m]>
* Discussion from project folks that have opinions pro or against the idea
<JamesMunns[m]>
I'm kind of leading both of the discussions (170 for rechartering, 159 for rust society). I'm generally trying to figure out at least the long term plan for 159 before we execute on 170, if that makes sense
<JamesMunns[m]>
IMO, under this proposal, we'd form:
<JamesMunns[m]>
* An embedded rust society chapter
<JamesMunns[m]>
* One or more sub-chapters for different teams, like the arm team, riscv team, etc.
<adamgreig[m]>
I dunno if we'd need to formally have the sub-chapters for each team vs just having teams on gh to organise things like crates ownership and repo access but otherwise have everyone in one chapter
<adamgreig[m]>
depends how the lines are drawn I guess! anyway not a very important problem yet
<JamesMunns[m]>
yep, that makes sense too!
<adamgreig[m]>
some of the sub-chapters would be pretty small :P
<JamesMunns[m]>
truth, the "github team chart" and "society chapter member list" don't need to (and probably shouldn't) overlap 1:1
<adamgreig[m]>
yea, that's what i'm thinking
jannic[m] has joined #rust-embedded
<jannic[m]>
Isn't embedded also a kind of cross-cutting-concern? Compiler support for several targets is only useful in embedded context. There are situations where embedded is quite special and may touch UB where "normal" rust code doesn't have any issues. We have special requirements regarding libs. etc.
<JamesMunns[m]>
When I say "cross cutting", it's more "cross cutting WITHIN the Rust project"
<JamesMunns[m]>
like handling CVE reports, or project goals, etc.
<JamesMunns[m]>
there is a somewhat implicit (but not universal) opinion that it makes sense to split "the people who ship the language" from "the people that use the language"
<JamesMunns[m]>
With the "Rust Project" being the former, and (with this proposal), the "Rust Society" being the latter
<jannic[m]>
Ok, makes sense. So we may interact with that team, eg. regarding some embedded-related goal, but we won't be part of that team.
<jannic[m]>
And if people from the (former) WG are also target maintainers of some embedded compiler target, that's the same as any other target maintainer from outside the project.
<adamgreig[m]>
yea, that's more or less the idea, though the level to which the new rust-soc members are "part of" the rust project is tbc I think
<JamesMunns[m]>
the two proposals for that are both "outside the project"
<adamgreig[m]>
"part of" the rust umbrella/trifecta I guess then?
<bartmassey[m]>
Why do folks want to bump people out? What does it accomplish?
<JamesMunns[m]>
one is "totally independent, with some recognition", one is "the rust soc organizers ('leadership council'?) are a rust team, but the larger group of members of the society/chapters are not"
<JamesMunns[m]>
but the general answer is that it's always been an awkward state of things, and it's hard to explain why other groups CAN'T do the same thing the embedded wg does.
<bartmassey[m]>
I guess my question is more that while it makes sense organizationally to separate the compiler and toolchain builders, it's hard for me to understand why other groups can't be a separate but official part of the Project under the Rust Society umbrella.
<bartmassey[m]>
Inclusivity seems like a feature here.
<JamesMunns[m]>
The answer becomes "where do you draw the line on what 'chapters' can be part of the project, and which ones can't"
<bartmassey[m]>
Is there really so much demand that this can't be handled case-by-case?
Darius has quit [Ping timeout: 248 seconds]
Darius_ has joined #rust-embedded
<jannic[m]>
Making an organization arbitrarily large has its own issues.
<bartmassey[m]>
Thanks for writing those reports BTW. They are great!
<dirbaio[m]>
also because "being part of the rust project" implies "being eligible for travel grants from the rust foundation" for example
<dirbaio[m]>
money isn't infinite
Darius_ is now known as Darius
<dirbaio[m]>
and it makes more sense that people who actually work on rustc get these travel grants
<bartmassey[m]>
The Foundation has processes for deciding who is eligible and who is awarded. I don't know if it makes more sense in general — some awfully important work is being done outside the compiler.
<JamesMunns[m]>
I'd expect this to make it easier to formalize things like "who gets invited to the unconf", having something like the rust society gives a structure with clear groups that could be invited
<dirbaio[m]>
"some people in the rust project are more core than others" makes things more complicated, idk
<bartmassey[m]>
As far as organizations getting larger, yes — some kind of better organization needs to be imposed. But at the point where it looks like the Rust leadership is making second-class citizens of some of its important contributors, I foresee issues down the road. We definitely don't need more toe-stubbing publicity at this point, and somebody is gonna get cranky. I was definitely envisioning Rust Society as as much an "official"
<bartmassey[m]>
part of Rust as the language itself, just a different kind of part.
<bartmassey[m]>
But that's just my opinion, man. I probably am wrong as I often am about these things.
<bartmassey[m]>
Anyway, sadly have to rush to class; I left comments on a couple of Jannic's issues. See you all next week!
<JamesMunns[m]>
fwiw: none of this is a made decision, YET, but it is getting very close to being so
<bartmassey[m]>
Gonna go teach some Rust Embedded now!
<JamesMunns[m]>
but, nobody has proposed anything else concrete + palatable to groups, including the rust project, so far.
<adamgreig[m]>
talking of bumping people out, shall we discuss the member cleanup briefly?
<jannic[m]>
If the rust society ends up as some totally unofficial collection of "everybody somehow interested in rust" without any representation or funding, there's not much reason to create it in the first place.
<adamgreig[m]>
jannic[m]: I think the hope is it ends up being an official collection of active rust users who are contributing to things that aren't the language/project itself
<adamgreig[m]>
whether that ends up with funding is a different point
<dirbaio[m]>
I personally think it makes sense for the Rust Project to focus on just rustc and core infra for the language (docs/books, crates.io, docs.rs, website)
<dirbaio[m]>
I personally don't contribute to rustc, so while it's cool to be able to say I'm part of the Rust Project i don't feel entitled to it
<jannic[m]>
dirbaio: It's cool enough that you can say you created embassy :-)
<adamgreig[m]>
yea, it's been convenient and useful for the wg, but I don't disagree with the principle
<JamesMunns[m]>
If we can enumerate the things we like, I would love to start encoding that in some of the "what is the rust soc" DNA
<adamgreig[m]>
what we like about being in the rust project?
<JamesMunns[m]>
or "how has the embedded wg benefitted from being part of the project"
<JamesMunns[m]>
with the implicit part of "and how can we and others continue that benefit"
<adamgreig[m]>
that's probably mostly things that we specifically won't get from not being in it, like the sort of official status, access to funding, representation on issues/council
<adamgreig[m]>
but I don't think any of those were ever very important
<JamesMunns[m]>
I know a couple people (jp and dario?) got funding
<adamgreig[m]>
or perhaps were never present in enough volume to become important anyway 😅
<JamesMunns[m]>
I'm certainly on the council as part of that representation
<adamgreig[m]>
yea, that's all stuff I'm referring to
<adamgreig[m]>
that was good about being in the project
<JamesMunns[m]>
I HAVE been trying to put in bits like "hey foundation you could totally open up grants or a class of them to recognized rust soc groups when it makes sense"
<adamgreig[m]>
some of the funding was set up in a way that might still continue, but I think the rust-lang managed funding would probably try to focus on actual rust project development (and project goals), which is totally fair enough
<JamesMunns[m]>
and maybe this does weigh stronger on the "rust soc council is a team under the launching pad so there's still a path to council representation"
<adamgreig[m]>
no fair reason the foundation should pay embedded people but not, say, gui people or games people or whatever to work on something or attend a conference
<adamgreig[m]>
but yea, if the foundation did financially sponsor some soc chapters that would certainly be nice, and be a reason for the society to exist/people to join it, but would need some careful thought about who/which groups get the money and where it comes from and such
<adamgreig[m]>
the "official status" is hard to say really. we probably got it de-facto by existing and continuing to exist, and I expect we'll keep it the same way, i.e. people will probably want to keep using embedded-hal as long as the ecosystem for it exists, and likely keep using the arch crates as long as they're maintained
<adamgreig[m]>
it would be hard to get that from scratch but that's not really a problem
<adamgreig[m]>
I would like to briefly talk about the member cleanup this week too: last time we used github teams chat or whatever to have a more private chat, but it doesn't exist any more I believe
<adamgreig[m]>
last time we basically just had a checkbox per team member for each team and you clicked it if you were still active/wanted to remain in the team, then we tried to get in touch with people who hadn't ticked it to check in personally, and anyone who felt like retiring we retired from the team
<adamgreig[m]>
we could do essentially the same thing with a new issue in the repo I guess?
<JamesMunns[m]>
adamgreig[m]: no objection from me!
<JamesMunns[m]>
maybe with a "contact Adam or Daniel on matrix/zulip/email if you want to discuss privately"?
<adamgreig[m]>
yea, makes sense
<adamgreig[m]>
ok, i'll post about it on the issue you opened to get any asyncronous feedback and then put something together in a few days
<adamgreig[m]>
jannic: thank you for the triage issues! I went through the easier ones and will try and tackle one harder one later...
<jannic[m]>
Regarding the triaged tickets. I see that there's already some new activity in the tickets I mentioned. That's why I do it, so: Thank you!
<adamgreig[m]>
that's all from me for this week I think, anything else in the last couple minutes?
<JamesMunns[m]>
Thanks to @adamgreig for running the show, as always :D
<adamgreig[m]>
now to remember to actually make the discussion topic for next week before I rush off home lol
<JamesMunns[m]>
oh, and if there are things that you want to talk to team members about, please mention them to me or someone who will be at RustWeek!
<JamesMunns[m]>
There are lots of cross-team sessions, and unconf folks can meet with teams to discuss stuff like code size, target support, volatile definition, etc.!
<JamesMunns[m]>
We should definitely take advantage of that if there are any items to discuss
<adamgreig[m]>
gosh, only 4 weeks away or so
<adamgreig[m]>
that's come by quickly
<adamgreig[m]>
we should start planning some of our unconf topics too
<adamgreig[m]>
ok, home time for me, see you all later!
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]>
(all of that with using pyserial-miniterm as a serial console. I'm gonna try screen which in the past served me well for exotic serial constellations...)
<dngrs[m]>
ok, with screen the embassy example works, but the non-embassy one exhibits the same infinite loop error
<dngrs[m]>
hmm, might've been a fluke, a subsequent run with screen causes garbage/unusable behavior. As I've experienced random boot loops on newline input with the C3 I can only conclude there's at least a race condition in noline
<dngrs[m]>
* hmm, might've been a fluke, a subsequent run with screen causes garbage/unusable behavior. As I've experienced random reboots on newline input with the C3 I can only conclude there's at least a race condition in noline
<dngrs[m]>
...yeah, now it works with miniterm.
pcs38 has quit [Quit: leaving]
LachlanIkeguchi[ has joined #rust-embedded
<LachlanIkeguchi[>
Who pinged?
M9names[m] has joined #rust-embedded
<M9names[m]>
It was a room-wide ping for the weekly meeting