Hey :wave: @T-compiler/WG-meta -- sorry, was running late today
hey, no worries, I was around waiting for your ping
I've two PRs of minutes notes
in general I'm merging all the minutes notes but the ones I do :)
just merged your PR
yeah...some of those I think we should turn into blog posts
on the new inside rust blog :)
seems like we are ALMOST ready for the ice-breaking
one pending this is https://github.com/rust-lang/team/pull/123
the changes didn't sound that bad
but I got scared when @Pietro Albini talked about integrations
I guess there's a good list of them
I just don't know how that is supposed to be "staged"
maybe we modify the integrations first to add
_ cases or whatever
but I got scared when Pietro Albini talked about integrations
I guess or either we provide a PR or wait for someone (on infra?) to do the work there?
I think maybe it's on us :)
I might enjoy hacking on the team repo a bit actually
well what I was thinking is a good "first PR" would be
#[non_exhaustive] to this enum
and propagate that
#[non_exhaustive]to this enum
did we stabilize this @centril I forget by now :)
PR is open.
I’ve got another PR to do relating to the interaction with improper_ctypes
@nikomatsakis unsure if I got what you meant right, do you want me to provide the non_exhaustive PR or are you doing so?
either way, really
probably better if you do it :)
well, I have the PR to add
right now it does require a feature gate tho
not sure if @Pietro Albini cares about that
plus there are the integrations
it looks like they are just git dependencies
so probably we have to (a) land the PR then (b)
cargo update -p those dependencies and fix the fallout?
I didn't check if they have lock files, but one hopes
heh well https://github.com/rust-lang-nursery/rustc-perf/tree/master/site doesn't appear to?
oh wait yes it does
@Santiago Pastorino if you're up for that, I say go for it, seems like you might as well roll those changes into your original PR then
gonna do that
also the non_exhaustive?
I can do that also
just trying to be sure we don't collide on the same stuff
also the non_exhaustive?
yes, I would do it in your same PR
that will force the integrations to write code that is fwd compatible with more additions to the enum
"hey, features working as designed"
well, I guess there's a question if that's good :)
but I guess at worst the website can just panic
yep, I'm already adding some bits of code :)
do you guys have a better name for
marker-team? :P, can't come with anything
it's like a low-traffic-team
unsure if there's a nice word to represent the intention in english
so, about the feature gate
for now a
__NonExaustive variant would be better
as adding the feature gate on the
rust_team_data would force every integration to switch to nightly
and at the moment I think only triagebot is on nightly
I'll review the PR when I'm actually awake :upside_down:
for now a
__NonExaustivevariant would be better
what do you mean by
to be clear about that
just a variant named that way
or a similar name
I guess you want me to add that variant to the enum and go over all the different crates that use the team repo to just do not do a match on it?
or match but always use a fallback?
basically going over the integrations and making sure they all have a default branch in the match
I personally don't think it is a _requirement_ to fix everyone
obviously it'd be appreciated :)
how does serde handle unknown variants when deserializing?
(don't remember off the top of my head)
ah, error? you can have a
#[serde(other)] though I think
Deserialize this variant if the enum tag is anything other than the tag of one of the other variants in this enum. Only allowed on a unit variant inside of an internally tagged or adjacently tagged enum.
which looks like that's not the default unfortunately (i.e., we don't have an internal/adjacent tag most likely)
yeah but if we add a variant with
#[serde(other)]] we'll still need to add a default match to every integration
I guess naming it
Unknown instead of
__NonExaustive and marking it
#[serde(other)] would be even better
I think we need to make sure that integrations don't break before they're redeployed
I'm saying that
#[serde(other)] won't work without more changes anyway
we're not adjacently or internally tagged
just pushed https://github.com/rust-lang/team/pull/123
what we should do is to send two PRs: the first add the support for MarkerTeam and the non exaustive thingy
then we update all the integrations
and finally we add the icebreakers team, once all the integrations are updated to properly understand the new variant
yeah I think so
seems good I can leave that PR there and open a new one with just the MarkerTeam stuff
I'll review it tomorrow
basically you meant a first PR that just updates rust_team_data and leave the src part for a later PR
we can have the src part on the first PR as well
we just can't have the actual team
thank god the team kind is the only enum in the static api
so we won't have to do this mess ever again
@Pietro Albini done https://github.com/rust-lang/team/pull/135
and then the old PR is back to just adding the team https://github.com/rust-lang/team/pull/123
@Santiago Pastorino the "it's not a marker team" is more for me to remember not to merge that PR as soon as the other is ready
I know you can't act on it right now while keeping CI green
I can make that PR be ready to be merge for once the other is merged so I can do
marker-team = true there
@Pietro Albini done
@Santiago Pastorino also done!
you can rebase