[rust-dev] Partial meeting agenda - older RFCs

Brian Anderson banderson at mozilla.com
Wed Jul 2 11:56:09 PDT 2014


On 07/02/2014 11:19 AM, Gábor Lehel wrote:
> Thanks, this is a good step, as is delaying taking actions by a day as 
> proposed in the meeting itself.
>
>
>     If you have any suggestions for how this regular email or the
>     process in general could be improved, please let us know.
>
>
> Most fundamentally, what I'm wondering is, why do most of the things 
> discussed at the meetings need to be discussed separately in the first 
> place?
>
> Why not have those discussions directly in the comments for the 
> respective RFC PRs? Up to and including leaving comments like "we 
> suggest closing this, because {justification}, unless someone 
> convinces us otherwise", "we suggest merging this because 
> {justification}", and so on. In an ideal world, the meetings could 
> merely ratify the decisions which were already evident from the PR 
> discussions themselves. This could also help avoid situations where 
> the two discussions end up disjoint in some way, e.g. according to 
> this week's meeting notes @pcwalton and @aturon essentially 
> recapitulated the exact same debate about the lifetime elision "self 
> rule" at the meeting which @aturon and I had previously gone through 
> in the PR comments.

I would like to move in this direction, but like many cultural changes 
it will be gradual. The primary reason we do so much in meetings is 
because face-to-face discussions move much faster and involve much less 
argumentation than asynchronous online discussions. In the immediate 
future I'd like to put more pressure on meeting participants to express 
their opinions on the issue ahead of meetings, which this initiative 
Nick is working on helps by making it clear what issues are coming up.

>
>
> From the proposed-for-discussion list:
>
>     https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for
>     prefix-style type parameter lists - ben0x539
>         Sugary syntax for putting a group of type parameters and their
>     bounds before a group of functions. Motivation is our often
>     unwieldly lists of type parameters.
>         Not much feedback, but mostly positive. Generally for the
>     motivation, rather than the solution.
>         Recommend close in deference to RFC 135 (where clauses) which
>     solve the motivating problem here, along with other issues.
>
>
> The two are complementary, not substitutive. 122 allows factoring out 
> type parameter lists for multiple declarations. 135 allows writing 
> them differently.
>
>
> From the meeting itself, because it concerns process:
>
>       * nrc: Do we want to keep this open? It's the |<>| to |[]| changes.
>       * acrichto: It's so new, I don't think we should close it.
>       * nrc: Even so, if we're not going to do it, I don't think we
>         should keep it open.
>
> I don't see what could have been gained by closing it. Potential 
> scenarios if it's left open:
>
>  (1) Participants end up convincing each other than the change is not 
> worth doing. (This is what ended up happening in this case.)
>  (2) Contrary to expectations, a consensus emerges in favor of the 
> change. Maybe there is some factor that hadn't been taken into account 
> previously, or the arguments of one side end up convincing the other. 
> I think this might be useful information to have learned. Then you can 
> evaluate the decision on the merits.
>
> Whereas if it's closed early:
>
>  (3) People are left with the opinions they already had, and now might 
> also have the impression that Mozilla has heavy-handedly shut down the 
> debate.
>
> I mean, possibly leave a comment like "Just so you know, we are 
> extremely unlikely to do this, but feel free to keep discussing", but 
> I think that was clear to everyone at the outset. I just don't see 
> what could have been gained by preventing the discussion from playing 
> itself out.
>
> Cheers,
> Gábor
>
>
>
> On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron <lists at ncameron.org 
> <mailto:lists at ncameron.org>> wrote:
>
>     Hi all, there have recently been some calls to be more open about
>     the Rust meetings, in particular to publish the agenda beforehand.
>     The agenda setting has been quite informal, often not coming
>     together until the meeting starts. Not to say that we won't
>     publish an agenda in the future, but that it is not as easy as it
>     might seem. However, as a step towards that, I will be mailing out
>     the part of the agenda that is set in advance which is the set of
>     (usually older) RFCs where discussion has mostly ceased and where
>     we feel we can make a decision on progress. This email is a
>     relatively new convention in any case. It has been sent to most
>     meeting attendees at the start of the week. From now on, I'll send
>     it to the mailing list instead. If you have comments on the RFCs,
>     please comment on the RFC PR itself, please do not reply to the
>     mailing list.
>
>     Some explanation of the process here - each week there are two
>     Rust meetings where we discuss RFCs, the general Rust meeting and
>     the triage meeting. We only accept RFCs at the general meeting.
>     RFCs may be closed at either meeting. In order to make sure no
>     older RFCs slip through the cracks, RFCs where discussion has come
>     to a stop (or nearly so) are recommended each week for discussion.
>     Based on the outcome of the discussion on the PR and the current
>     goals of the Rust project (in particular in not accepting any
>     major backwards compatible changes before 1.0) an RFC will be
>     proposed for discussion at the general meeting if it needs
>     discussion or we are likely to accept, or to the triage meeting if
>     it is likely to closed. To clarify, what actually happens to an
>     RFC is decided at the meeting, not by which meeting it is
>     discussed at. Often, other RFCs are also discussed at the meetings
>     where attendees think there is a more urgent need to discuss
>     something. You can see the minutes of the meeting discussions at
>     https://github.com/rust-lang/meeting-minutes. Not all the RFCs
>     proposed in this email get discussed at the meetings - either
>     because we run out of time or because a key person is not at the
>     meeting.
>
>     The 'actions agreed' section keeps track of actions on older RFCs
>     agreed at previous meetings, but which have not yet been carried out.
>
>     If you have any suggestions for how this regular email or the
>     process in general could be improved, please let us know.
>
>     Cheers, Nick
>
>
>     Proposed for discussion at Rust meeting
>     ---------------------------------------
>
>     https://github.com/rust-lang/rfcs/pull/16 - attributes on
>     statements and blocks
>         huon has updated
>         should we accept now?
>
>     https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family
>     - erikt
>         No recommendation, just needs a kick to get moving again.
>
>     https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax
>     for module imports - tommit
>         Allow e.g., `use module::{self, Type};` for `use module::Type;
>     use module;`.
>         Generally positive response. Some bike shedding around the use
>     of `self` since we call the file mod.rs <http://mod.rs>, and some
>     proposal to allow self.rs <http://self.rs> instead.
>         Recommend we accept (possibly we should bikeshed the synax
>     `self`). We could postpone this (it would be backwards
>     compatible), but it seems very desirable and would be little
>     effort to implement.
>
>     https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures -
>     nmatsakis
>         A lot of discussion, pretty much all about the details.
>     General sentiment that we want this.
>         Recommend we accept - is this the right RFC to accept, I've
>     not really been keeping track - pnkfelix, pcwalton - is there
>     something which supersedes this? I think this needs a small update
>     to reflect some of the later comments.
>
>     https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to
>     trusted - stevelabnik
>         Loads of opinion in the thread (162 comments!). Note that Niko
>     has an upcoming RFC with the concept of unsafe/trusted traits
>     where the keyword `trusted` makes a lot more sense than `unsafe`,
>     so we could save a keyword here.
>         Recommend we discuss this.
>
>     https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic
>     operators to take their arguments by value not by ref - pcwalton.
>         Pretty negative feedback (though not all). I remember being
>     convinced this was the proper way to implement arithmetic
>     operators a while back, but I can't remember why (something about
>     using tuples in the signature maybe? I can't remember). There
>     seems to be some poor interaction with BigInt, etc. where
>     implementing for `&BigInt` isn't what you want (but I don't see
>     why from the comment, pcwalton seems to in his reply though).
>         Lets discuss this.
>
>
>     Proposed for discussion at triage
>     ---------------------------------
>
>     https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe
>     initialised' pointers (pretty much out params, aiui) - gereeter
>         A new form of reference, `&uninit`, is added that is
>     write-only and points to possibly uninitialized data.
>         Mixed reactions - overall positive, but agreement on low priority.
>         Recommend close as postponed - was this agreed last week?
>
>     https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer
>     overflow - bmyers
>         Proposes range types and other complicated stuff, but
>     discusses other options.
>         Lots of discussion on integer overflow in general, no
>     agreement. Also discussed to death on the mailing list several
>     times, including currently.
>         Recommend close - we might conceivably do something, but we
>     won't do this and we won't lose anything by closing this RFC
>     (there's also a new RFC with a different proposal derived from the
>     most recent mailing list thread).
>
>     https://github.com/rust-lang/rfcs/pull/119 - add support to
>     serialize::json for incrementally reading multiple JSON objects -
>     XMPPwocky
>         Apparently this is included in RFC 22, which has an
>     implementation.
>         Recommend close in deference to RFC 22.
>
>     https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do'
>     keyword as sugar for nested match statements - bvssvni
>         Syntax for flattening match statements by 'chaining' arms of a
>     match statement.
>         Feedback is mostly negative. Some positive feelings for
>     including the macro rather than first class syntax. Others want to
>     wait for HKT and have a function.
>         Recommend close as postponed. We probably want something like
>     this, but not pre-1.0.
>
>     https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for
>     prefix-style type parameter lists - ben0x539
>         Sugary syntax for putting a group of type parameters and their
>     bounds before a group of functions. Motivation is our often
>     unwieldly lists of type parameters.
>         Not much feedback, but mostly positive. Generally for the
>     motivation, rather than the solution.
>         Recommend close in deference to RFC 135 (where clauses) which
>     solve the motivating problem here, along with other issues.
>
>
>     Actions agreed
>     --------------
>
>     https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a
>     stream of tagged values - erikt
>         Changes to the deserialisation framework. Allows for decoding
>     into an enum. No commentary for or against.
>         erikt to update?
>
>     https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count
>     sequence repetitions - Eridius
>         More discussion - esp, can it be done with a macro
>
>     https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern
>     matching for slices - krdln
>         No comments. The RFC is a little bit vague, but seems like
>     kind of a win. Backwards incompatible.
>         Close.
>
>
>     _______________________________________________
>     Rust-dev mailing list
>     Rust-dev at mozilla.org <mailto:Rust-dev at mozilla.org>
>     https://mail.mozilla.org/listinfo/rust-dev
>
>
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140702/0638f805/attachment.html>


More information about the Rust-dev mailing list