-
Notifications
You must be signed in to change notification settings - Fork 1k
Add minutes for the SIP meeting in October 2016 #629
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,173 @@ | ||
--- | ||
layout: sip-landing | ||
title: SIP Meeting Minutes - 25th October 2016 | ||
--- | ||
|
||
# Minutes | ||
|
||
The following agenda was distributed to attendees: | ||
|
||
| Topic | Reviewer | | ||
| --- | --- | | ||
| Discussion of the voting system | N/A | | ||
| [SIP-20: Improved Lazy Val Initialization](http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html) | Sébastien Doeraene | | ||
| [SIP-27: Trailing commas](https://github.com/scala/scala.github.com/pull/533#issuecomment-232959066) | Eugene Burmako | | ||
|
||
Jorge Vicente Cantero was the Process Lead and acting secretary of the meeting. | ||
|
||
* **Decided to reaccept for review**: SIP-27: Trailing commas | ||
* **Under review**: SIP-20: Improved Lazy Val Initialization | ||
|
||
## Date, Time and Location | ||
|
||
The meeting took place at 5:00pm Central European Time / 8:00am Pacific Daylight | ||
Time on Tuesday, October 25th, 2016 via Google Hangouts. | ||
|
||
Minutes were taken by Jorge Vicente Cantero, acting secretary. | ||
|
||
## Attendees | ||
|
||
Attendees Present: | ||
|
||
* Martin Odersky ([@odersky](https://github.com/odersky)), EPFL | ||
* Seth Tisue ([@SethTisue](https://github.com/SethTisue)), EPFL | ||
* Iulian Dragos ([@dragos](https://github.com/dragos)), Independent | ||
* Heather Miller ([@heathermiller](https://github.com/heathermiller)), Scala Center | ||
* Sébastien Doeraene ([@sjrd](https://github.com/sjrd)), EPFL | ||
* Eugene Burmako ([@xeno-by](https://github.com/xeno-by)), EPFL | ||
* Jorge Vicente Cantero ([@jvican](https://github.com/jvican)), Process Lead | ||
* Adriaan Moors ([@adriaanm](https://github.com/adriaanm)), Lightbend | ||
|
||
## Apologies | ||
|
||
* Josh Suereth ([@jsuereth](https://github.com/jsuereth)), Google | ||
|
||
## Proceedings | ||
### Opening Remarks | ||
|
||
After some controversy sprung by the [latest SIP-27 | ||
vote](https://github.com/scala/scala-lang/pull/477), the SIP Process Lead | ||
cancelled the vote on the SIP-27: Trailing Commas, and invited the Committee to | ||
discuss new voting rules to help clarify the process voting system. | ||
|
||
The issue was caused by a legal void on the rounding of the 70% rule. | ||
Traditionally, votes are not rounded up. However, the SIP Process Lead | ||
took the decision to round up the SIP-27 vote percentage, which was 66%. | ||
This decision was taken in the best spirit of the rule, which was only introduced | ||
to ensure that simple majorities (50%) are not enough for accepting a proposal. | ||
|
||
Before the meeting, the SIP Process Lead shared this email with all the | ||
Committee members: | ||
|
||
> The majority-plus-two rule sets a concrete threshold and fits the spirit of | ||
> the rule (not having simple majority, but a | ||
> [supermajority](https://en.wikipedia.org/wiki/Supermajority)). The 70% rule is | ||
> too strict, especially for committees that are not big, as ours. After some | ||
> research, we can choose the [two-thirds | ||
> rule](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) used in a | ||
> lot of political parties, parliaments, boards and committees. | ||
|
||
### Deciding the voting system | ||
|
||
Sébastien starts the discussion pointing out that he would like to have a simple | ||
percentage, without any rounding. Heather argues that this percentage changes | ||
depending on the number of the present Committee Members. Seth comments that | ||
it has been proposed in several online channels that all the Committee members | ||
should vote, even if they cannot attend the meeting. All the Committee agrees on | ||
this, but the main consequence is that the voting period is not predictable | ||
anymore, since there's not a fixed deadline to vote. Martin proposes to choose | ||
this fixed deadline case-by-case. | ||
|
||
Martin proposes that there's a meta rule to only accept a proposal if 50% of | ||
all the Committee members vote for it, and then to have another percentage on | ||
the actual vote. Seth, Eugene and Heather don't like this idea. Heather brings | ||
up the issue of abstentions, should they still be considered as no's even if | ||
people are on vacation or cannot vote?. Adriaan says this is a fair concern, and | ||
thinks that there should be a fixed deadline for voting. | ||
|
||
All the Committee agrees that with the new rules the Committee wouldn't vote | ||
publicly, because Committee members can notify their vote after the meeting and | ||
before the fixed deadline. | ||
|
||
Martin proposes to keep the old rules, the 70% percentage rule. Jorge proposes | ||
to have simpler and more predictable rules, and replace 70% with the two-thirds | ||
rule. Martin comes back to the abstentions point: he doesn't want them to be | ||
considered as no, because with the current rules Committee members could block | ||
the whole decision process. Some Committee members point out that this wouldn't | ||
happen because then the quorum wouldn't be reached. The discussion shifts | ||
towards the quorum point: is it necessary anymore? Heather and Adriaan say that | ||
it is, because it ensures that a reasonable number of Committee members meet to | ||
discuss proposals and convince each other about the pros and cons. All the | ||
Committee finally decides to not consider abstentions as no's. Adriaan, however, | ||
suggests that we should penalize people that abstain too often. | ||
|
||
Another system proposed by Martin helps survive the abstention issue mentioned | ||
before. For a proposal to pass, at least 50% of all the Committee | ||
and two-thirds of all the people voting (not counting abstentions) must accept | ||
it. The quorum rule is kept. After some discussion, the Committee unanimously | ||
votes in favor of the new rules. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not clear from these notes which alternative was accepted in the end. Some more detail should be devoted to explaining the voting rule in the minutes. So far, to my knowledge, this is the only place the rule has been written so far. Has the SIP process been updated with the new voting rule? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, I'm on my way to do so. I would prefer to leave the minutes as they are and put all the examples and a clear specification in the process submission rules. |
||
|
||
### Discussion of SIP-27: Trailing Commas | ||
|
||
Eugene describes what happened in the last meeting. Martin asks if there is a | ||
concrete proposal. Jorge says that he thinks that Dale would push for the new | ||
line specialized case. Martin proposes to push for a more concrete proposal | ||
because the specification cannot be so open-ended to properly analyze the | ||
consequences of the suggested changes. | ||
|
||
Seth and Adriaan voice their opinions on trailing commas again, they don't agree | ||
this is a problem that should be solved in the language. Martin changes his view | ||
on the subject, and provided that the proposal does no harm to the syntax of the | ||
language and doesn't cause problems, he would accept the change. He also says | ||
that it wouldn't be good to contradict last month's vote on the proposal. | ||
Heather says that she's in favor of trailing commas because makes beginners be | ||
less confused by the syntax and help people get started with the language. | ||
Iulian doesn't like the specialized version, he would prefer a general version. | ||
|
||
**Outcome**: All the Committee decides to vote on accepting the proposal again for a final | ||
review with a clear specification of the changes. Seth and Adriaan vote against, | ||
the rest of the Committee except Josh vote in favor of it. According to our new | ||
rules, Josh gets to decide whether the proposal will be readmitted for review or | ||
cancelled (**NOTE**: Josh votes in favor of trailing commas one week after the | ||
meeting). Trailing commas will be reviewed in November. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand. Are we still waiting on Josh's vote? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, Josh has already voted in favor. There was a typo: votes instead of voted. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So then this was accepted? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, not yet. Dale didn't decide on a concrete change of the syntax, so Martin wants to check the final spec and see its implications. We're voting on it this month (29th November) since Dale has already submitted the changes and decided for one of the three options he proposed in its last specification. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We're voting a 3rd time? I really don't get this. The minutes definitely don't make it any clearer. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In other words, after the controversy about the process rules, we were deciding whether the trailing commas proposal should be reviewed again or automatically rejected. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. None of this was clear in the meeting or in the minutes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Forcing everyone to vote (including Josh) for a non-binding vote on whether to review this again is a bit weird, to be honest. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It may not be clear in the minutes, I will update it. There may have been some confusion during the meeting... here's the moment when Martin proposed it: https://youtu.be/tXYs9e6Qrb8?t=2266. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The vote was for my benefit: before I go off spending hours updating the SIP for the next meeting, let's check if it wouldn't be rejected regardless. It's no guarantee it'll be accepted, but I'm grateful for the vote. |
||
|
||
### Discussion of SIP-20: Improved Lazy Val Initialization | ||
|
||
Sébastien comments the changes that Dmitry has introduced to the proposal. | ||
Several new schemes have been added to the proposal based on his experience in | ||
Dotty, in which the championed scheme is already implemented. | ||
|
||
There are no clear winner in the case of local lazy vals, but there seems to be | ||
two clear candidates for the non-local lazy vals (B4-general and B6). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There should be a link to the proposal so the reader can consult what B4 and B6 are, exactly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed. |
||
Both are faster than the existing implementation in the contended case but B4 | ||
general is 4x and B6 is only 2x. However, for the uncontended case B4 general is | ||
30% slower than the existing implementation, while B6 is on par, up to +-5%. | ||
Dmitry recommends the B6 case because it's a *pure* win. Memory-wise, B6 would | ||
have a smaller memory footprint. | ||
|
||
Sébastien comments on the increase of the bytecode for the getter of the lazy | ||
val, which is 4x bigger. This could make a difference, although the benchmarks | ||
do not show any negative impact of it (probably because the previous | ||
implementation was bigger than the limits set by the JVM to benefit from | ||
code inlining). | ||
|
||
Jorge comments that there's no implementation of this proposal for scalac. This | ||
means that someone should step up and provide such implementation, because | ||
Dmitry does not have time for it. Adriaan comments on the fact that B6 uses | ||
`sun.misc.Unsafe`, which he prefers that the compiler doesn't depend on to run | ||
in other platforms that don't allow it (Google App Engine). Sébastien highlights | ||
that the proposal could use var handles, which are planned to be shipped on Java | ||
9. | ||
|
||
Heather proposes to mark this proposal as dormant, since it's lacking an | ||
implementation. She wants to let other people claim its ownership and provide an | ||
implementation if they care about this issue. | ||
|
||
**Outcome**: The Committee agrees to mark the proposal as dormant and let | ||
someone pick it up and provide an implementation. Ideally, this implementation | ||
should run in Java 8 and don't depend on var handles. The SIP Process Lead will | ||
wait some time to receive another candidate from the current author, Dmitry. If | ||
he doesn't propose anything, the SIP will be marked as dormant. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is contradictory. At the beginning of this paragraph, it says this is marked as redundant. Then at the bottom it says that we'll wait for someone to be proposed before marking it dormant. Which is it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, it's contradictory because we changed our mind several times during the discussion. The one at the end is the final decision. I would update this part of the document to make it clearer. |
||
|
||
## Closing remarks | ||
See you next time! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lightbend, not EPFL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me explain everything in the submission process, and we discuss the clarity of the rules there 😄. If necessary, I can come back to these minutes and modify them accordingly or link to the actual changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Can you fix my affiliation before merging, please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, count on it.