Possibly some of this is driven by how GitHub automatically spams a large number of people with the conversations. While I'm sure the core team is more patient than me, I don't want to listen to twenty years worth of debate about semicolons in a dead RFC. ;D
Kevin On Wed, Jul 2, 2014 at 11:19 AM, Gábor Lehel <glaebho...@gmail.com> 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. > > > 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 <li...@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, and some proposal to allow 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@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev