You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

8.1 KiB

io.js TC Meeting 2015-01-28

Agenda

Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.

  • governance: Add new Collaborators #234 / feedback and more contribs / @chrisdickinson
  • Stabilization and Release Cycles and Process #405 / further discussion / @iojs/tc
  • dgram: implicit binds should be exclusive #325 / minor version bump / @bnoordhuis
  • buffer: implement iterable interface #525 / minor version bump / @bnoordhuis
  • replace util.isType() with typeof #607 / general use of util.is*() in core re perf
  • docs: lower the maximum stability level to "stable" #633
  • maintain our own package registries for io.js related packages #640
  • Working Groups PR #599
  • Remove “unstable” from messaging #108

Minutes

Present

  • Ben (TC)
  • Bert (TC)
  • Chris (TC)
  • Colin (TC)
  • Fedor (TC)
  • Isaac (TC)
  • Mikeal
  • Rod

Apologies from:

  • Trevor (TC)
  • Domenic

Mini stand-up

  • Ben: Reviewed/landed pull requests, fixed bugs, the usual
  • Bert: Same as Ben, but not as much
  • Chris: On-boarding stuff
  • Colin:
  • Fedor: working on pyg (gyp alternative in C)
  • Rod: ARMv6 builds, fixing persistent bug on Ubuntu 10.04, yay!
  • Isaacs: Only doing npm CEO stuff
  • Mikeal: social media stuff for io.js, PR, roadmap, feedback from Big Cos.

Review of last meeting

governance: Add new Collaborators

#234 / feedback and more contribs / @chrisdickinson

Stabilization and Release Cycles and Process

#405 / further discussion / @iojs/tc

Also: doc: add releases document detail release cycle #630 / proposal from @chrisdickinson

Moved straight to Chris’ proposal:

  • Chris discussed thoughts in his proposal @ https://github.com/iojs/io.js/issues/630
  • Mikeal: would rather not have a static number/list of supported versions, let that be dynamic as people & companies step up to help support them
  • Ben: “stable” and “next” would be easiest to reason about
  • Chris: “dev” is for ad-hoc semver releases, replaces nightlies with a better train system.
  • Chris: branches will be “master” - development happens here, maintain “v1.x”, “v2.x” etc. for major releases. Ideally LTS would be from major versions.
  • Fedor asked about communication to users and how much fragmentation this would cause
  • Ben: how do you keep the delta between dev and stable from getting too big
  • Chris: at most there would be a 2-week lag between something hitting dev and something going out on stable
  • Bert: suggested that we need a better batching mechanism, particularly for breaking changes, so we’re not constantly bumping major.

dgram: implicit binds should be exclusive

#325 / minor version bump / @bnoordhuis

  • Ben: this is about minor version bump, that’s been decided and we’re doing a 1.1.0 so this is being merged and released

buffer: implement iterable interface

#525 / minor version bump / @bnoordhuis

  • Ben: same as previous issue, resolved

replace util.isType() with typeof

#607 / general use of util.is*() in core re perf

  • Bert: find with direct comparisons and checks where it makes sense (undefined, simple stuff)
  • Isaac: hate it all, they are difficult to inline so manually inline--pick one and use it across all
  • Colin: working on a PR to do the replacement already
  • Chris volunteered to PR a style-guide into docs
  • Isaac: better linter would be great

Doc-tool - Should we merge with the joyent/node version?

  • Isaac: Robert Kowalski reached out to me to ask about this.
    • Seems silly to have two nearly-identical tools for this.
    • Delegate to doc working group?
    • Suggested that he just pick one from io.js or joyent/node and send a PR for that
  • Mikeal: Website WG is meeting next week, will pull in Robert to that discussion

docs: lower the maximum stability level to "stable"

#633

  • General disagreement about this
  • Mikeal suggested moving things that are likely to change into vendored packages (like streams)
  • Motivation was to set some things (frozen/locked) as unchangable because they would break too much stuff
  • Bert: we effectively have 4 levels: strict-deprecation, soft-deprecation, moving, pretty-much-done
  • Mikeal: proposed punting this for a few weeks
  • Isaac: the labels are useful for guiding people on where best to contribute and where to not bother

#640

  • Mikeal: each distro (Homebrew, Debian, etc.) has their own conception of “stable”, suggestion is to maintain them under io.js and instruct people how to do this. e.g. using our own custom Homebrew end-point and instruct people how to use it with brew. Also could bring in complicated packages from the community.
  • Mikeal: Should come under the Build WG for now, ideally a single repo where external projects can put in a single PR to update their stuff.

Working Groups PR

#599

  • Mikeal introduced his proposal: if you’re going to do the work in a WG then you can spin that up as a separate concern
  • Ben asked for clarification about whether WGs get a free-pass in core
    • Mikeal: no, they are isolated from core
  • Rod: clarification about relationship to TC
    • TC has charter-revocation powers, beyond that they don’t have control over the activities of a WG
  • Consensus reached, Mikeal will put in the suggested fixes (in the PR) into the docs and merge

Remove “unstable” from messaging

#108

  • Remove “unstable” from the website but not say it’s “stable”
  • Bert: big +1, use semver, don’t try and message something else, only concern is the version of V8 we are using
  • Discussed V8 4.1 and how “stable” it is

Node.js and io.js should not break each other (no, they shouldn't)

#631

Rod brought this up for quick discussion and draw attention to TC members for possible input.

  • Mikeal suggested that this should be taken to the website WG for better documentation

Working group reports

  • Streams
  • first WG meeting this week
  • Website
  • meeting next week

Next meeting

  • 4th of February