search

rust-lang / wg-allocators

Home of the Allocators working group: Paving a path for a standard set of allocator traits to be used in collections!
http://bit.ly/hello-wg-allocators
207 stars 9 forks source link

Decision making in the WG #20

Closed SimonSapin closed 4 years ago

SimonSapin commented 5 years ago

I’ve added this to @rust-lang/libs’s agenda for the 2019-05-15 meeting. Discussion or suggestions are welcome from anyone.

gnzlbg commented 5 years ago

Should this working group have formal membership? If so, how does one join?

Usually one pings the facilitator, and they just add them to the repo, such that @rust-lang/wg-allocators pings all members. We should document this in the readme.

Does @rust-lang/libs delegate any authority to the WG? To what extent?

I think that the goal of the wg should be to produce RFCs that go through the process. PRs from the group to rust-lang/rust would need libs team review as usual. I don't think we need any special kind of status for the WG right now. EDIT: That is, I expect the libs team to check on what this group is doing regularly, and participate in it, as well as maybe "bless" RFC-drafts before they are submitted as RFCs, but IMO we should just follow the normal process after that, where each lib team member needs to sign on any important changes.

Should @rfcbot be used to run the FCP process and formally record consensus?

I think this is up to the people in the working group to decide. The tool is there, if we think we need it we should use it. It's unclear to me how useful it would be at this stage. If the repo contains RFC-drafts that we plan to submit, those would be send to the repo as PR, and the members can just review them and approve them, so we can also track consensus there (e.g. if everyone approves a PR to this repo, then it's good to go).

TimDiekmann commented 5 years ago

Should the output of the WG go through the RFC process at https://github.com/rust-lang/rfcs, to involve the wider Rust project and community?

Yes, I don't think this WG should have a special position. But we should not go through the whole RFC process. I think a FCP would be enough in the most cases.

Should @rfcbot be used to run the FCP process and formally record consensus?

If we decide not to go through the whole RFC process for small changes (e.g. Alloc - > AllocHandle), this is a suitable solution. Those changes should be tracked in the WGs repo, either by code (#19) or by some text files. I'd prefer the former. When an area has been finished (e.g. How we want Box<T, A> to be implemented) this will go through the FCP at rust-lang/rust.

How do we actually decide on this issue?

SimonSapin commented 5 years ago

Yes, I don't think this WG should have a special position. But we should not go through the whole RFC process.

I think these two sentences are strictly contradictory.

TimDiekmann commented 5 years ago

What I wanted to say is that it makes no sense for small changes to always start the complete RFC machine and instead combine several changes within the WG as pre-RFC. After this, we file this RFC to rust-lang/rust.

SimonSapin commented 5 years ago

Oh ok. Yes we can definitely “batch” changes into a smaller number of separate RFCs in https://github.com/rust-lang/rfcs.

Ericson2314 commented 5 years ago

I would hope that WG can get "expedited" landing of unstable changes like the eRFC concept. Of course stabilization must and should require a full RFC.

SimonSapin commented 5 years ago

The libs team discussed at yersterday’s triage meeting… but didn’t have much to say.

Process-wise, it’s fine to make any change whenever to unstable APIs. Any stabilization should go through an RFC, as usual. Other than that, it’s up to the WG to self-organize however we want.

I think it can be useful to use this repository both for code with faster iteration time than the homu queue for rust-lang/rust, and for collaborating on draft RFCs.

I think https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.html can serve as a de-factor eRFC for this WG, even though we didn’t use that term at the time. Note that an eRFC does not expedite anything, it is merely an agreement to start work in rust-lang/rust on a large unstable feature, without having the final design yet. (As opposed for example to not accepting at all a PR that starts implementing coroutines without https://rust-lang.github.io/rfcs/2033-experimental-coroutines.html.)

TimDiekmann commented 4 years ago

It has been about half a year since the workgroup was formed and not a single decision has been made since. I think it has turned out who is active in the WG. I would suggest that we either use the FCP-bot or do it manually, but if that continues, we haven't made a decision in a year.

@ErichDonGubler It would be great to have a statement by you regarding this as you wanted to lead this WG.

ErichDonGubler commented 4 years ago

@TimDiekmann I admit that I've let this particular WG fall off my radar for a while. I've been keeping up with discussion, and haven't seen a need to moderate, but I agree with the sentiment that having somebody to shepherd tasks forward would be the most helpful at this point.

To that end, I'll commit to pushing tasks forward from this point. I'm going to take an hour or two to refresh myself on the contents of this issue, and reply here with more thoughts then. I'm probably going to need some help to do it correctly, but I'm interested in developing a summary of this WG's progress and the current design of allocators, including open questions.

Thoughts?

ErichDonGubler commented 4 years ago

Originally, I volunteered to be a facilitator for this working group. To lean heavily on @Manishearth's definition in his relevant blog post:

At a high level, the job of the facilitators is to:

  • help foster empathy between participants
  • help linearize complex discussions
  • nudge towards cooperative behavior, away from adversarial behavior. Get people playing not to win, but to win-win.

By this definition, I feel @TimDiekmann's expectation to "lead" wasn't previously established. That's why I haven't taken an active role in pushing discussion forward until this point. I have been paying attention to tone and whether or not some clarification would have served to faciliate discussion in one issue or another, and until now I haven't felt that there have been any emotional or technical standstills that required my assistance.

That said, from what I see, this working group could benefit enormously from some renewed interest, and I feel that the most helpful thing I can do for the WG would be to encourage people to participate. I think that interest will naturally drive issues to completion. As a facilitator, I can do better in encouraging participants to fulfill commitments they make or to take certain actions that would drive an issue. So, let me rescind my previous statement here:

I'm going to take an hour or two to refresh myself on the contents of this issue, and reply here with more thoughts then. I'm probably going to need some help to do it correctly, but I'm interested in developing a summary of this WG's progress and the current design of allocators, including open questions.

...and try to express my intent better: I'm interested in developing a summary of this WG's progress and the current design of allocators, including open questions. My intent is to do so and then use that summary to encourage people to come and participate.

ErichDonGubler commented 4 years ago

To @TimDiekmann's point, it seems like the discussion here is getting stale, so I'll try to do my part as facilitator and summarize what I think is happening in this issue so far. Correct me if I'm wrong or misrepresent you, please! :) I'll use the @SimonSapin's OP content to structure the summary.

  • Should this working group have formal membership?
    • If so, how does one join?

@gnzlbg stated that just talking to a facilitator (that's me) and getting added to Zulip is sufficient. I see this as pretty relaxed, I don't see a reason to keep this process more restrictive at this point. Does anyone else?

  • Should @rfcbot be used to run the FCP process and formally record consensus?

[snip]

[snip]

  • When and how should changes to the standard library land?

So, there's a distinction embedded in these points between:

  • Does @rust-lang/libs delegate any authority to the WG? To what extent?

@gnzlbg is the only participant that has responded to this, indicating he thinks no.

What would this authority be used for, exactly? I don't think I understand this question.

[snip]

  • Should there be code experiments outside of the standard library first? On crates.io? CC #19

The only argument I can see against this is if the design we want for allocators requires deep integration with Rust upstream. Otherwise, implementation and feedback loop could be significantly streamlined. Am I missing something here?

I didn't do a particularly good job of being neutral in this case, but...here's my first post trying to actively be a facilitator! :) Woot!

gnzlbg commented 4 years ago

What would this authority be used for, exactly? I don't think I understand this question.

I think this was resolved by @SimonSapin in this comment: https://github.com/rust-lang/wg-allocators/issues/20#issuecomment-493130013

TimDiekmann commented 4 years ago

How much effort is it to add the FCP bot? I propose to FCP #8 to rename Alloc to AllocRef.

TimDiekmann commented 4 years ago

Ping @ErichDonGubler

How much effort is it to add the FCP bot? I propose to FCP #8 to rename Alloc to AllocRef.

TimDiekmann commented 4 years ago

I like to start pushing things upstream to nightly. For this I think (for now a manual) FCP should be enough to decide which things to push. Until #2 is resolved, it's not possible to modify stabilized structs, but it's definitely possible to modify the Alloc trait, which is probably the first thing this WG wants to push forward.

We don't have a fixed list of members of this WG. I'll link the people who has contributed to the discussions in this WG. Additionally, I like to link @Wodann and @Lokathor from the gamedev-wg. For now please vote, if I should link you in the FCP process.

If you don't have the permissions to modify comments in this repository, please vote :+1: :-1: instead. If you are not linked, but want to decide, please also vote :+1:

gnzlbg commented 4 years ago

cc @amanieu - they also participated in some of the discussions.

SimonSapin commented 4 years ago

(I’ve removed my name from the list, as I’m less available these days to be actively involved in this WG.)

TimDiekmann commented 4 years ago

Thanks @gnzlbg, I added him :slightly_smiling_face:

scottjmaddox commented 4 years ago

@TimDiekmann Thanks for including me! I'm happy to contribute however I can. Is there any documentation on what the responsibilities/expectations are?

TimDiekmann commented 4 years ago

@scottjmaddox It's just deciding, which features should be pushed upstream to nightly (e.g. rename Alloc to AllocRef etc.). If you are fine, that a proposals lands on nightly, you simply tick the box. If you have concerns, you post them.

Which account of you I should link?

Lokathor commented 4 years ago

Voted for FCP approval

TimDiekmann commented 4 years ago

So, we are 8 people voting to merge changes upstream. At how many votes we should push things, as long as no concerns are listed? 6? 7? 8?

Lokathor commented 4 years ago

I think T-lang allows up to 2 people to have not voted as long as no one objected and a minimum time has passed.

6/8 and no objections seems fine as long as long as it's been say, 72 hours or more. This is all experimental Nightly work anyway, so anything critical can be fixed along the way.

TimDiekmann commented 4 years ago

Reevaluation

Is the current way on how I submit PRs upstream fine to everyone? At seems, that the people of this WG has moved a bit. Currently, those are active:

CC @gnzlbg @Ericson2314 @scottjmaddox @glandium

scottjmaddox commented 4 years ago

I'm happy to provide feedback, but it's also fine if I'm not in the approval loop. If I am included, I will do my best to respond in a timely manner. I leave the choice up to you.

vertexclique commented 4 years ago

Same, even I didn't comment much here I am closely watching the progress and suggestions. Feel free to count on me. I can be also in the loop and will respond timely manner.