diff options
| author | Rich Trott <rtrott@gmail.com> | 2019-11-11 17:28:01 -0800 |
|---|---|---|
| committer | Rich Trott <rtrott@gmail.com> | 2019-11-13 21:17:07 -0800 |
| commit | ed401236f6988c6ad62a21dbbf808da83782bee0 (patch) | |
| tree | 2f9a72a791f5a0714721da00bd27f9444a92d80f /BUILDING.md | |
| parent | 78dbe74520d36de7f7bc17707848ec8ec63e67a5 (diff) | |
| download | android-node-v8-ed401236f6988c6ad62a21dbbf808da83782bee0.tar.gz android-node-v8-ed401236f6988c6ad62a21dbbf808da83782bee0.tar.bz2 android-node-v8-ed401236f6988c6ad62a21dbbf808da83782bee0.zip | |
doc: remove "maintenance is supported by" text in BUILDING.md
The "maintenance is supported by" stuff in BUILDING.md is unclear. It
seems unnecessary so I propose removing it.
I don't understand what it means to, in this context, support
maintenance. Does it mean that you simply do the maintenance? Does that
mean it really just means "maintain"? Do we really mean that we mantain
support, rather than support maintenance?
That information does not seem necessary to include. I'm not sure it's
meaningful. With (for example) Windows, is it accurate to say that the
Node.js core team maintains support for it? Or is it accurate to say
that support is maintaned by smaller groups or individuals within the
Node.js core team? Both could be considered accurate. So is the
difference meaningful?
I think the more important elements of determinig tier support are the
other listed elements.
PR-URL: https://github.com/nodejs/node/pull/30365
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Diffstat (limited to 'BUILDING.md')
| -rw-r--r-- | BUILDING.md | 15 |
1 files changed, 6 insertions, 9 deletions
diff --git a/BUILDING.md b/BUILDING.md index d4c8f63aa1..97580266f8 100644 --- a/BUILDING.md +++ b/BUILDING.md @@ -69,17 +69,14 @@ There are three support tiers: * **Tier 1**: These platforms represent the majority of Node.js users. The Node.js Build Working Group maintains infrastructure for full test coverage. - Maintenance is supported by the Node.js core team. All commits to the - Node.js repository are tested on multiple variants of these platforms. Test - failures on tier 1 platforms will block releases. + All commits to the Node.js repository are tested on multiple variants of these + platforms. Test failures on tier 1 platforms will block releases. * **Tier 2**: These platforms represent smaller segments of the Node.js user base. The Node.js Build Working Group maintains infrastructure for full test - coverage. Maintenance is supported by smaller groups or individuals within - the Node.js core team, or the vendor of the platform itself. All commits to - the Node.js repository are tested on multiple variants of these platforms - where practical. Test failures on tier 2 platforms will block releases. - Delays in release of binaries for these platforms are acceptable - where necessary due to infrastructure concerns. + coverage. All commits to the Node.js repository are tested on multiple + variants of these platforms where practical. Test failures on tier 2 platforms + will block releases. Delays in release of binaries for these platforms are + acceptable where necessary due to infrastructure concerns. * **Experimental**: May not compile or test suite may not pass. The core team does not create releases for these platforms. Test failures on experimental platforms do not block releases. Contributions to improve support for these |