On Thu, Jul 3, 2014 at 6: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.
>
> Please comment on the RFCs rather than replying to the mailing list. I'll
make a note of this, but in the general case, I guarantee that replies to
the mailing list will get lost or forgotten. I agree the two RFCs are not
substitutive and could both be accepted, but they do both tackle the same
problem (ugly type param lists).
>
> 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.
>
> We will (at some point) have a separate discussion on the policy, as was
briefly touched upon in the meeting we decided it was a policy question and
we shouldn't do anything in this case.
My motivation for early closure of some RFCs is to be honest - I don't want
to waste people's time, energy, or emotional investment arguing about it if
they have the (false) impression that it might change. As you suggest
leaving a comment and leaving the RFC open is probably a better way to do
this (although you can still comment on a closed PR, so I'm not sure there
is really much difference, other than whether the RFC shows up in the list
of open PRs). Another reason is simply that I don't like to see pointless
arguing, and I feel that on RFCs like this which come down to taste, it
really is arguing and not discussion. I think the Rust community would be a
better place without it. Of course, I could just ignore the GitHub spam,
but I would rather the arguing just doesn't happen. FWIW, your point 1 is
very valid and probably outweighs my points, just saying that there are
other disadvantages. The chance of 2 happening in a case like this seems so
small that I wouldn't worry about it.
Cheers, Nick
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
