Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Call for vote on reverting runtime deprecation of using Buffer without new on v7 #36

Closed
evanlucas opened this issue Nov 23, 2016 · 30 comments

Comments

@evanlucas
Copy link

evanlucas commented Nov 23, 2016

Ref: nodejs/node#9529

/cc @nodejs/ctc

I would like for us to come to a resolution before next week if possible.

If you are in favor of reverting the change, please comment with +1
If you are in favor of leaving the change in, please comment with a -1
If you would like to abstain from the vote, please comment with abstain


VOTE STATUS TABLE

Vote Count
In favor 7 (@addaleax @evanlucas @jasnell @indutny @mhdawson @thealphanerd @ofrobots)
Opposed 3 (@ChALkeR @mscdex @thefourtheye)
Abstain 6 (@Fishrock123 @Trott @cjihrig @shigeki @bnoordhuis @rvagg)
Total needed to pass/reject 7
Not yet voted 3 (@chrisdickinson @misterdjules @trevnorris)

Total needed to pass/reject is calculated with:

const ctcSize = 19;
return Math.floor((ctcSize - abstainVotes) / 2) + 1;
@addaleax
Copy link
Member

+1

1 similar comment
@evanlucas
Copy link
Author

+1

@ChALkeR
Copy link
Member

ChALkeR commented Nov 23, 2016

-1 for reverting now.

We don't have the current usage data (working on that), and I am uncertain how would this affect the future deprecation of Buffer(arg).

@Trott
Copy link
Member

Trott commented Nov 23, 2016

we don't have the current usage data

For the benefit of people who weren't at the meeting: This is data you are collecting and expect to have next week some time? (Correct me if I'm wrong about that, of course!)

I am uncertain how would this affect the future deprecation of Buffer(arg).

For clarity, is this a correct understanding?: You are opposed to removing this deprecation in version 7 if it means that we are not committed to a runtime deprecation in version 8. Removing in version 7 with a plan to put it back in version 8 might be OK. But removing and never putting it back is unacceptable.

@joshgav
Copy link
Contributor

joshgav commented Nov 23, 2016

Notes from today's CTC meeting on this are here and in #37.

@ChALkeR
Copy link
Member

ChALkeR commented Nov 23, 2016

This is data you are collecting and expect to have next week some time.

That is just the data on how the usage of Buffer(arg) without new has changed in the topmost packages — that would be available soon, hopefully in two days.

Taking dependencies into an account is harder, and that doesn't work yet in an automatic way, so it probably won't be ready next week.

You are opposed to removing this deprecation in version 7 if it means that we are not committed to a runtime deprecation in version 8. Removing in version 7 with a plan to put it back in version 8 might be OK. But removing and never putting it back is unacceptable.

Yes, that is correct. One notice, though — putting it back should have a «deprecated for security reasons» warning, a link to the explanation (on the reasons behind and how to fix things), and we probably should decide on the messaging of this before doing the revert in question here.

@jasnell
Copy link
Member

jasnell commented Nov 23, 2016

+1 for reverting the current runtime deprecation. My preference would be to
replace with a new off-by-default deprecated-in-docs notice as suggested in
my recent pr.

On Wed, Nov 23, 2016 at 9:04 AM Evan Lucas notifications@github.com wrote:

Ref: nodejs/node#9529 nodejs/node#9529

/cc @nodejs/ctc https://github.com/orgs/nodejs/teams/ctc

I would like for us to come to a resolution before next week if possible.

If you are in favor of reverting the change, please comment with +1
If you are in favor of leaving the change in, please comment with a -1
If you would like to abstain from the vote, please comment with abstain


You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#36, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAa2eWBbp6_qlG8ZJDYPsMlEnM6pFktQks5rBHIzgaJpZM4K61SV
.

@indutny
Copy link
Member

indutny commented Nov 23, 2016

👍

@Fishrock123
Copy link

Abstaining

@ChALkeR
Copy link
Member

ChALkeR commented Nov 23, 2016

@indutny, is that +1? (Just trying to be clear 😄).

Some old stats from a month ago: on 2016-10-22, there were approx. 1372 packages directly affected by this deprecation, 1127 were affected outside of the tests directories.

New stats (from today) will be available soon.

I can't tell the exact number of indirectly affected packages atm, though, but I'm going to do a rough estimation.

@Trott
Copy link
Member

Trott commented Nov 23, 2016

Abstaining, at least for now. I think this runtime deprecation should be rolled back for version 7, but I share @ChALkeR's concern that this might become a (bad) reason to never runtime deprecate the Buffer constructor ever. "We tried to deprecate it once before and it was horrible for everyone."

@Trott
Copy link
Member

Trott commented Nov 23, 2016

(I added a table indicating the status of the vote in the opening comment for this issue.)

@cjihrig
Copy link

cjihrig commented Nov 23, 2016

Abstain

@mhdawson
Copy link
Member

+1 to revert.

@MylesBorins
Copy link

MylesBorins commented Nov 23, 2016 via email

@mscdex
Copy link

mscdex commented Nov 23, 2016

-1

@shigeki
Copy link

shigeki commented Nov 24, 2016

abstain from this voting

@bnoordhuis
Copy link
Member

Abstaining. (I'll update the table.)

@thefourtheye
Copy link

-1

@ChALkeR
Copy link
Member

ChALkeR commented Nov 25, 2016

Some stats on Buffer-without-new usage are here now!

Notes:

  • «total matches» and «total packages» do not affect end users, as those include matches in tests dirs, those affect only maintainers/authors of those packages.
  • «integral downloads» doesn't take versions into an account (there are no per-version download stats from npm), so it counts only those packages which have their latest version affected.
  • Doesn't include nested deps, only direct hits.
  • «integral downloads» are normalized using the current downloads/month stats.
  • There are false positives and false negatives, these stats are crude.
  • The matches/packages counts were increasing or staying at the same level because of the new packages (npm grows quite fast), but old and popular packages migrate away from buffer-without-new, hence the integral downloads/month drops rapidly.

Taking that into an account, this still does provide some useful data. It could be seen that most part of the popular packages moved away from using buffer-without-new, but we have about 40% of the usage (counting by download stats) still there.


2016-08-04

  • 4862 total matches
  • 1020 total packages
  • 2151 matches outside of test dirs
  • 753 packages with matches outside of test dirs
  • 29842894 integral downloads/month (outside of test dirs)

2016-10-22

  • 5406 total matches
  • 1110 total packages
  • 2420 matches outside of test dirs
  • 821 packages with matches outside of test dirs
  • 19448511 integral downloads/month (outside of test dirs)

2016-10-25

7.0.0 release

2016-11-24

  • 5399 total matches
  • 1112 total packages
  • 2328 matches outside of test dirs
  • 816 packages with matches outside of test dirs
  • 12385330 integral downloads/month (outside of test dirs)

Note: I updated the stats a bit, fixing some false positives and false negatives. I could be updating these in-place later without a further notice.

@addaleax
Copy link
Member

@chrisdickinson @misterdjules @ofrobots @rvagg @trevnorris It would be great if you could indicate your preference or abstain from voting so that we have a resolution before the next release.

@ofrobots
Copy link

+1

@rvagg
Copy link
Member

rvagg commented Nov 27, 2016

I have to abstain unfortunately, I have opinions but without having fully reviewed all of the (many) comments on this topic I don't feel it's responsible of me to weigh it either way!

@rvagg
Copy link
Member

rvagg commented Nov 27, 2016

@ChALkeR does your vote get changed at all after looking at the stats? Does it sway you further in either way after you look at that?

@ChALkeR
Copy link
Member

ChALkeR commented Nov 27, 2016

@rvagg I did not yet check the nested depencencies, but some points:

  • This deprecation doesn't seem to be helping with the security issue, for the already mentioned reasons — it basically just forces a quick replacement Buffernew Buffer without caring about the usecase. We can file individual issues, though.
  • This deprecation does seem to be having a noticeable effect on Buffer-without-new usage — that reduced significantly.
  • I am still unsure if reverting this deprecation will put an obstruction to runtime-deprecating Buffer(arg with or without new, also note the lack of understanding how this should be messaged — those are my main concerns here, and atm the sole reason for -1.

Nevertheless, the vote has already passed, 7 + 6/2 > 19/2, and the decision is to revert.

@Trott
Copy link
Member

Trott commented Nov 28, 2016

Appears to be resolution on the narrow issue here so I'm going to remove the ctc-agenda label. Feel free to re-add if this is something we need to talk about at the meeting this week.

@Trott Trott removed the ctc-agenda label Nov 28, 2016
@Fishrock123
Copy link

Is there a PR for this already? Someone will need to make it today to be able to release this week. Please do so ASAP.

@evanlucas
Copy link
Author

@evanlucas
Copy link
Author

I'm going to go ahead and close as the vote passed and the revert has landed on master. Thanks!

@trevnorris
Copy link

belated abstention. from the conversations I've had it seems this decision won't affect the long term API direction of Buffer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests