New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dedicated strike team to resolve unsafe code guidelines #1643

Merged
merged 2 commits into from Aug 15, 2016

Conversation

Projects
None yet
@nikomatsakis
Contributor

nikomatsakis commented Jun 7, 2016

Incorporate a strike team dedicated to preparing rules and guidelines for writing unsafe code in Rust (commonly referred to as Rust's "memory model"), in cooperation with the lang team. The discussion will generally proceed in phases, starting with establishing high-level principles and gradually getting down to the nitty gritty details (though some back and forth is expected). The strike team will produce various intermediate documents that will be submitted as normal RFCs.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Jun 7, 2016

Contributor

I am interested as well.

Contributor

ticki commented Jun 7, 2016

I am interested as well.

@glaebhoerl

This comment has been minimized.

Show comment
Hide comment
@glaebhoerl

glaebhoerl Jun 7, 2016

Contributor

Something I'd've expected the RFC to mention:

What's the motivation for forming a separate "strike team" to take on this responsibility, instead of making it a priority for one or more of the existing teams*? Is it expected that the membership of the strike team will have minimal overlap with the existing teams? Otherwise, if it's mostly the same people, the amount of capacity they have available to dedicate to the effort will be a constant independently of what team rosters they appear on. Of course the phrase "strike team" evokes swift and decisive progress, and everyone's in favor of swift and decisive progress, but naming aside why is this special-case organizational structure felt to be necessary and expected to be effective in this case? (And why not for other major priorities? What aspect of this one makes the difference?)

* The RFC writes "It is the contention of this RFC that a complete guidelines for unsafe code are far too big a topic to be fruitfully addressed in a single RFC. Therefore, this RFC proposes the formation of a dedicated strike team" -- but I don't see how these are connected. There's no reason in principle why the effort couldn't be structured as a multi-RFC process as described without a dedicated strike team, or for that matter why a strike team couldn't have creating a single "big bang" RFC as its objective.

Contributor

glaebhoerl commented Jun 7, 2016

Something I'd've expected the RFC to mention:

What's the motivation for forming a separate "strike team" to take on this responsibility, instead of making it a priority for one or more of the existing teams*? Is it expected that the membership of the strike team will have minimal overlap with the existing teams? Otherwise, if it's mostly the same people, the amount of capacity they have available to dedicate to the effort will be a constant independently of what team rosters they appear on. Of course the phrase "strike team" evokes swift and decisive progress, and everyone's in favor of swift and decisive progress, but naming aside why is this special-case organizational structure felt to be necessary and expected to be effective in this case? (And why not for other major priorities? What aspect of this one makes the difference?)

* The RFC writes "It is the contention of this RFC that a complete guidelines for unsafe code are far too big a topic to be fruitfully addressed in a single RFC. Therefore, this RFC proposes the formation of a dedicated strike team" -- but I don't see how these are connected. There's no reason in principle why the effort couldn't be structured as a multi-RFC process as described without a dedicated strike team, or for that matter why a strike team couldn't have creating a single "big bang" RFC as its objective.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Jun 7, 2016

Member

@glaebhoerl The intent is that the strike team will include members not currently on subteams, and hopefully act in consultation with academics and other experts.

As @nikomatsakis says, the lang team is expected to be heavily involved in some of the higher-level aspects, but we need people who can devote significant time to working out the details as well, and don't have the resources on the lang team alone.

(I agree that the way the RFC explains this isn't very clear.)

FWIW, I'm also a bit uneasy about the expectation that the artifacts here will end up going through the normal RFC process as well. I think we should try to get some clarity on who and how the decisions are going to be made.

Separate concern: as someone who's spent some time on formal memory models (the concurrency side of C/C++11), I have significant respect for the problem space -- there are many open research problems in memory models, and many mistakes made over the course of years-long efforts by myriad experts. I think we need to go about this in a humble and open-ended way, with an emphasis on incremental, conservative gains. I think @nikomatsakis has done a good job of pushing in this direction by delineating the scope and highlighting some intermediate artifacts, but I'm hoping that we can reach further clarity on that front in this RFC thread.

Member

aturon commented Jun 7, 2016

@glaebhoerl The intent is that the strike team will include members not currently on subteams, and hopefully act in consultation with academics and other experts.

As @nikomatsakis says, the lang team is expected to be heavily involved in some of the higher-level aspects, but we need people who can devote significant time to working out the details as well, and don't have the resources on the lang team alone.

(I agree that the way the RFC explains this isn't very clear.)

FWIW, I'm also a bit uneasy about the expectation that the artifacts here will end up going through the normal RFC process as well. I think we should try to get some clarity on who and how the decisions are going to be made.

Separate concern: as someone who's spent some time on formal memory models (the concurrency side of C/C++11), I have significant respect for the problem space -- there are many open research problems in memory models, and many mistakes made over the course of years-long efforts by myriad experts. I think we need to go about this in a humble and open-ended way, with an emphasis on incremental, conservative gains. I think @nikomatsakis has done a good job of pushing in this direction by delineating the scope and highlighting some intermediate artifacts, but I'm hoping that we can reach further clarity on that front in this RFC thread.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 8, 2016

Contributor

FWIW, I'm also a bit uneasy about the expectation that the artifacts here will end up going through the normal RFC process as well. I think we should try to get some clarity on who and how the decisions are going to be made.

I would be open to changing this, but I still think it's a good idea. I think there are a lot of people who pay attention to RFCs, but don't follow the minute details -- they would probably want to know that a larger decision is on the cusp of being made.

On the other hand, maybe we can just advertise that another way, but it seems like we have an existing RFC channel, so why not use it?

One counter argument might be that we won't actually be ready to settle on a "high-level approach" (for example) until the detailed approach is nearly done, at which point there will be a lot of resistance to changing -- but that seems ok to me. If crucial flaws are found, great, we can fix them -- and if not, then we can continue moving forward.

Contributor

nikomatsakis commented Jun 8, 2016

FWIW, I'm also a bit uneasy about the expectation that the artifacts here will end up going through the normal RFC process as well. I think we should try to get some clarity on who and how the decisions are going to be made.

I would be open to changing this, but I still think it's a good idea. I think there are a lot of people who pay attention to RFCs, but don't follow the minute details -- they would probably want to know that a larger decision is on the cusp of being made.

On the other hand, maybe we can just advertise that another way, but it seems like we have an existing RFC channel, so why not use it?

One counter argument might be that we won't actually be ready to settle on a "high-level approach" (for example) until the detailed approach is nearly done, at which point there will be a lot of resistance to changing -- but that seems ok to me. If crucial flaws are found, great, we can fix them -- and if not, then we can continue moving forward.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 8, 2016

Contributor

@glaebhoerl

What's the motivation for forming a separate "strike team" to take on this responsibility, instead of making it a priority for one or more of the existing teams*? Is it expected that the membership of the strike team will have minimal overlap with the existing teams?

Yes, that is expected and the point.

Contributor

nikomatsakis commented Jun 8, 2016

@glaebhoerl

What's the motivation for forming a separate "strike team" to take on this responsibility, instead of making it a priority for one or more of the existing teams*? Is it expected that the membership of the strike team will have minimal overlap with the existing teams?

Yes, that is expected and the point.

@Diggsey

This comment has been minimized.

Show comment
Hide comment
@Diggsey

Diggsey Jun 12, 2016

Contributor

Will there be a stabilisation period for changes to the unsafe code guidelines?

Contributor

Diggsey commented Jun 12, 2016

Will there be a stabilisation period for changes to the unsafe code guidelines?

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Jun 20, 2016

Contributor

Will there be a stabilisation period for changes to the unsafe code guidelines?

I think that makes a lot of sense, especially since existing code may well depend on subtle details in the way unsafe code is expected to be used.

While we can likely make changes to undefined behavior compatibly in theory, we definitely should make sure we've thought through the way any changes to the way unsafe code is intended to be used will affect existing code.

Contributor

wycats commented Jun 20, 2016

Will there be a stabilisation period for changes to the unsafe code guidelines?

I think that makes a lot of sense, especially since existing code may well depend on subtle details in the way unsafe code is expected to be used.

While we can likely make changes to undefined behavior compatibly in theory, we definitely should make sure we've thought through the way any changes to the way unsafe code is intended to be used will affect existing code.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 27, 2016

Contributor

Will there be a stabilisation period for changes to the unsafe code guidelines?

It probably makes sense to try and follow the process for features as much as possible -- this would imply an FCP for the "RFC", and then a secondary stabilization period. In the interim, I would expect that we'll make strides on modifying the compiler to take advantage of these new guidelines when optimizing, as well as surveying code for compliance, so that we can have a good feeling for how things are working out.

Contributor

nikomatsakis commented Jun 27, 2016

Will there be a stabilisation period for changes to the unsafe code guidelines?

It probably makes sense to try and follow the process for features as much as possible -- this would imply an FCP for the "RFC", and then a secondary stabilization period. In the interim, I would expect that we'll make strides on modifying the compiler to take advantage of these new guidelines when optimizing, as well as surveying code for compliance, so that we can have a good feeling for how things are working out.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 27, 2016

Contributor

Nominating for FCP.

Contributor

nikomatsakis commented Jun 27, 2016

Nominating for FCP.

@aturon aturon added the T-core label Jun 27, 2016

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 29, 2016

Contributor

lgtm. I think this would be improved with some language about the conditions for disbanding the strike team; once these things are accomplished, the team's work is done.

Contributor

brson commented Jun 29, 2016

lgtm. I think this would be improved with some language about the conditions for disbanding the strike team; once these things are accomplished, the team's work is done.

@ubsan

This comment has been minimized.

Show comment
Hide comment
@ubsan

ubsan Jun 30, 2016

Contributor

@brson is it? I look at C++, and their "strike teams" are never finished -- they have a team for gamedev, a team for the memory model, a team for everything. It seems to work out pretty well for them.

Contributor

ubsan commented Jun 30, 2016

@brson is it? I look at C++, and their "strike teams" are never finished -- they have a team for gamedev, a team for the memory model, a team for everything. It seems to work out pretty well for them.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 30, 2016

Contributor

@brson is it? I look at C++, and their "strike teams" are never finished -- they have a team for gamedev, a team for the memory model, a team for everything. It seems to work out pretty well for them.

Once there's a spec covering the memory model, I don't see what significant ongoing work there will be that can't be folded into the existing project structure. Whether the team is expected to exist forever or to have a finite purpose and then end, I would like it to be addressed.

Contributor

brson commented Jun 30, 2016

@brson is it? I look at C++, and their "strike teams" are never finished -- they have a team for gamedev, a team for the memory model, a team for everything. It seems to work out pretty well for them.

Once there's a spec covering the memory model, I don't see what significant ongoing work there will be that can't be folded into the existing project structure. Whether the team is expected to exist forever or to have a finite purpose and then end, I would like it to be addressed.

@ubsan

This comment has been minimized.

Show comment
Hide comment
@ubsan

ubsan Jun 30, 2016

Contributor

@brson Nowhere is the intention of this team to create a specification, unless this team is supposed to start the Rust specification. There is no Rust specification.

(barring my personal project which is empty, because I haven't upstreamed any local changes yet)

Contributor

ubsan commented Jun 30, 2016

@brson Nowhere is the intention of this team to create a specification, unless this team is supposed to start the Rust specification. There is no Rust specification.

(barring my personal project which is empty, because I haven't upstreamed any local changes yet)

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 30, 2016

Contributor

@brson Nowhere is the intention of this team to create a specification, unless this team is supposed to start the Rust specification. There is no Rust specification.

Thanks for the correction @ubsan. Please consider my previous comment to apply to whatever documentation this team is going to produce.

Contributor

brson commented Jun 30, 2016

@brson Nowhere is the intention of this team to create a specification, unless this team is supposed to start the Rust specification. There is no Rust specification.

Thanks for the correction @ubsan. Please consider my previous comment to apply to whatever documentation this team is going to produce.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jul 1, 2016

Contributor

Like @brson, I assumed that the purpose of this team was indeed limited in duration. That is, the team exists for the purpose of doing the sprint work to produce the initial documents described within. After that, smaller questions can presumably be resolved by the normal RFC process -- which would of course include input from the strike team members!

Contributor

nikomatsakis commented Jul 1, 2016

Like @brson, I assumed that the purpose of this team was indeed limited in duration. That is, the team exists for the purpose of doing the sprint work to produce the initial documents described within. After that, smaller questions can presumably be resolved by the normal RFC process -- which would of course include input from the strike team members!

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 1, 2016

Contributor

After thinking more about the difference in meaning between 'team', 'subteam', and 'strike team', I do find it attractive for us to get to a place where many teams are flourishing in some official capacity. It wouldn't be a bad thing - it would be really great - for the teams page to be filled with many, many active contributors. The bigger Rust gets (and it's going to get really big) the more people need to be empowered to make decisions. But still I am inclined to push back on expansions of the bureaucracy, and want us to make those changes carefully.

Contributor

brson commented Jul 1, 2016

After thinking more about the difference in meaning between 'team', 'subteam', and 'strike team', I do find it attractive for us to get to a place where many teams are flourishing in some official capacity. It wouldn't be a bad thing - it would be really great - for the teams page to be filled with many, many active contributors. The bigger Rust gets (and it's going to get really big) the more people need to be empowered to make decisions. But still I am inclined to push back on expansions of the bureaucracy, and want us to make those changes carefully.

@ubsan

This comment has been minimized.

Show comment
Hide comment
@ubsan

ubsan Jul 2, 2016

Contributor

@brson I think the current bureaucracy is inefficient in part because some people are doing a lot of jobs at once. If we could just have more people doing less... We know that there are people in the community who want to help, but their skills aren't really fully utilized since everything needs to go through six people (and from personal experience, it just feels kind of hopeless when you're in that position).

Edit: not just six people. Six people who are also in charge of compilers, libraries, tooling and infrastructure, community, and moderation, depending on the person.

@eddyb - lang and compiler
@nrc - lang, compiler, tooling+infra
@pnkfelix - lang, compiler, moderation
@nikomatsakis - core, lang (lead), compiler (lead)
@aturon - core, lang, libs (lead)
@huonw - core, lang, libs

(I'm referring to my own experience here, dealing with the lang team; I'm not sure if other people with different teams have the same experience, but I know at least one other has had this experience with the lang team).

Contributor

ubsan commented Jul 2, 2016

@brson I think the current bureaucracy is inefficient in part because some people are doing a lot of jobs at once. If we could just have more people doing less... We know that there are people in the community who want to help, but their skills aren't really fully utilized since everything needs to go through six people (and from personal experience, it just feels kind of hopeless when you're in that position).

Edit: not just six people. Six people who are also in charge of compilers, libraries, tooling and infrastructure, community, and moderation, depending on the person.

@eddyb - lang and compiler
@nrc - lang, compiler, tooling+infra
@pnkfelix - lang, compiler, moderation
@nikomatsakis - core, lang (lead), compiler (lead)
@aturon - core, lang, libs (lead)
@huonw - core, lang, libs

(I'm referring to my own experience here, dealing with the lang team; I'm not sure if other people with different teams have the same experience, but I know at least one other has had this experience with the lang team).

@notriddle

This comment has been minimized.

Show comment
Hide comment
Contributor

notriddle commented Jul 4, 2016

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Jul 11, 2016

Member

This RFC is entering its final comment period. The main point on which we need to reach final consensus is the precise "success conditions" (and whether the team is disbanded). This question intersects considerably with the ongoing discussion around refinements to the RFC process, but if possible we shouldn't block getting going on this team on those broader questions.

Member

aturon commented Jul 11, 2016

This RFC is entering its final comment period. The main point on which we need to reach final consensus is the precise "success conditions" (and whether the team is disbanded). This question intersects considerably with the ongoing discussion around refinements to the RFC process, but if possible we shouldn't block getting going on this team on those broader questions.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jul 18, 2016

Contributor

The main point on which we need to reach final consensus is the precise "success conditions" (and whether the team is disbanded).

It seems to me that the "success conditions" would be producing the various documents cited in the RFC. That is, the team exists to produce the initial version of those documents.

I'm not sure what I think about longer-lived "subsubteams" yet -- I go back and forth -- but I do feel pretty sure that this RFC wouldn't be the right place to establish such a thing. I feel like that's creating permanent structure is a more fundamental change more, akin to #1068, and hence worthy of being discussed separately.

Contributor

nikomatsakis commented Jul 18, 2016

The main point on which we need to reach final consensus is the precise "success conditions" (and whether the team is disbanded).

It seems to me that the "success conditions" would be producing the various documents cited in the RFC. That is, the team exists to produce the initial version of those documents.

I'm not sure what I think about longer-lived "subsubteams" yet -- I go back and forth -- but I do feel pretty sure that this RFC wouldn't be the right place to establish such a thing. I feel like that's creating permanent structure is a more fundamental change more, akin to #1068, and hence worthy of being discussed separately.

The unsafe code guidelines team is intended as a temporary strike team
with the goal of producing the documents described below. Once the RFC
for those documents have been approved, responsibility for maintaining
the documents falls to the lang team.

This comment has been minimized.

@ubsan

ubsan Jul 26, 2016

Contributor

I'd argue the docs team is a better team for this (even if they don't yet exist).

@ubsan

ubsan Jul 26, 2016

Contributor

I'd argue the docs team is a better team for this (even if they don't yet exist).

This comment has been minimized.

@GuillaumeGomez

GuillaumeGomez Aug 3, 2016

Member

I guess for now it makes more sense since the doc doesn't exist like you said. 😉

@GuillaumeGomez

GuillaumeGomez Aug 3, 2016

Member

I guess for now it makes more sense since the doc doesn't exist like you said. 😉

@erkinalp

This comment has been minimized.

Show comment
Hide comment
@erkinalp

erkinalp Aug 1, 2016

@ubsan: We really need a spec and then csn define what are common and what are accepted variance for porting.

erkinalp commented Aug 1, 2016

@ubsan: We really need a spec and then csn define what are common and what are accepted variance for porting.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 15, 2016

Contributor

Huzzah! The @rust-lang/core team has decided to accept this RFC.

If this stuff is of interest to you, you probably want to subscribe to this internals category:

https://internals.rust-lang.org/t/about-the-unsafe-code-guidelines-category/3706

Contributor

nikomatsakis commented Aug 15, 2016

Huzzah! The @rust-lang/core team has decided to accept this RFC.

If this stuff is of interest to you, you probably want to subscribe to this internals category:

https://internals.rust-lang.org/t/about-the-unsafe-code-guidelines-category/3706

@nikomatsakis nikomatsakis merged commit b8ae71c into rust-lang:master Aug 15, 2016

@brson brson referenced this pull request Sep 23, 2016

Merged

Add the style team #523

@chriskrycho chriskrycho referenced this pull request Dec 31, 2016

Closed

Document all features in the reference #38643

0 of 17 tasks complete

@chriskrycho chriskrycho referenced this pull request Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete

@nikomatsakis nikomatsakis referenced this pull request Apr 24, 2017

Merged

Trait alias. #1733

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment