On Wed, Jul 2, 2014 at 11:05 PM, Nick Cameron <li...@ncameron.org> wrote:
>
>
>
> 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).
>
OK. I didn't miss that admonishment in the original e-mail. I had the
impression that it referred to general commentary, rather than replies to
specific things in the e-mail itself. It feels strange to reply to a
statement in a venue where the statement hasn't been made.
>
>> 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
>
>From a philosophical perspective, as with democracy (which I recognize this
is not), I think the value is not necessarily in the outcomes but in the
process itself. People are more likely to be constructive and accepting of
the outcome if they feel that they've gotten their fair say. (For what it's
worth, I didn't perceive this particular discussion as arguing.)
>
> 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
