Bug #7820: Let's decide Ruby 2.0 supported platform list

• Status: Closed
• Assignee: mame (Yusuke Endoh)
• Target version: 2.0.0
• ruby -v: 2.0.0-rc2

[mame (Yusuke Endoh)]

I'm sorry I didn't talk about Ruby 2.0 supported platforms earlier.

At first, I think that the primary purpose of "the supported platform list" is to help users see how much Ruby is tested in their platforms.

For this purpose, the current list for Ruby 1.9 [1] has too many categories with difficult, developer-oriented rules, and its wording like "Best effort" may sound too optimistic a little for users.
In addition, nowadays, there are some useful CIs available, such as rubyci.org (by Naruse-san) and ci.rubyinstaller.org (by Naruse-san and Luis Lavena + EngineYard).

[1] http://bugs.ruby-lang.org/projects/ruby-trunk/wiki/SupportedPlatforms

So, I propose two rough and simple categories:

• well-cared: the platform is included in rubyci.org or ci.rubyinstallers, and is usually green
• maintained: not "well-cared", but there is a platform maintainer

(I'd like a native speaker to propose a better wording)

• well-cared

  • Ubuntu 10.04 64-bit
  • Debian 6.0.5 (wyhaines?)
  • CentOS 5.6 x86_64/i386
  • RHEL, CentOS6 (kosaki)
  • FreeBSD (knu)
  • Mac OS X (mrkn)
  • mingw (nobu)

• maintained

  • nacl (actually inclueded in Ruby CI, but looks constantly red）
  • mswin32, mswin64 (usa)
  • CentOS5 (Eric Wong)
  • IA-64 (Debian GNU/Linux) (takano32)
  • OpenBSD (Jeremy Evans)
  • AIX (kanemoto)
  • Solaris (ngoto)
  • Symbian OS (azov)

Some may think that a "platform" consists of not only OS and CPU, but also a compiler and related libraries. However, in terms of the purpose, it is not necessarily useful to make it pedantic, I think.

Note that this is just an idea. What do you think?

--
Yusuke Endoh [e-mail]

[jonforums (Jon Forums)]

A great idea to simplify and clarify!

Perhaps listing support tiers instead of "well-cared" and "maintained"?

• Tier 1: the platform has a public CI (normally green) and is maintained by a ruby-core committer
• Tier 2: the platform is maintained by a ruby-core committer
• 3rd Party: best-effort support by members of the ruby community (e.g. - https://fedoraproject.org/wiki/Ruby_SIG)

Note that the 3rd Party tier is an opportunity for commercial and non-commercial parties to get a form of (non-endorsed) advertisement.

While it should be self evident that just because a platform (e.g. Arch Linux) is not listed in any support tier doesn't mean MRI won't build/test/install on that platform, consider adding something much shorter than the sentence you just finished. Essentially, "try it, and if it breaks let us know."

Consider dropping the OS version as it's misleading and often out-of-date. For example, listing "Ubuntu 10.04 64bit" can be misinterpreted as meaning ruby-core is only supporting an outdated OS version. I know this to be false as I regularly test on Ubuntu 12.10 32bit and 64bit.

Instead of listing mingw, mswin32, mswin64 consider:

• Tier 1:

  • Windows 7/8 32/64bit with mingw/mingw-w64 toolchain (nobu)

• Tier 2:

  • Windows 7/8 32/64bit with mswin toolchain (usa)

Yes, I'm in favor of dropping "official" support for XP and ready to dodge the arrows for advocating for it ;)

Jon

[kosaki (Motohiro KOSAKI)]

On Sat, Feb 9, 2013 at 8:11 PM, jonforums (Jon Forums)
[e-mail] wrote:

Issue #7820 has been updated by jonforums (Jon Forums).

A great idea to simplify and clarify!

Perhaps listing support tiers instead of "well-cared" and "maintained"?

• Tier 1: the platform has a public CI (normally green) and is maintained by a ruby-core committer
• Tier 2: the platform is maintained by a ruby-core committer

I like a name of tier[12].

• 3rd Party: best-effort support by members of the ruby community (e.g. - https://fedoraproject.org/wiki/Ruby_SIG)

Note that the 3rd Party tier is an opportunity for commercial and non-commercial parties to get a form of (non-endorsed) advertisement.

While it should be self evident that just because a platform (e.g. Arch Linux) is not listed in any support tier doesn't mean MRI won't build/test/install on that platform, consider adding something much shorter than the sentence you just finished. Essentially, "try it, and if it breaks let us know."

In this case, 3rd party want to use their own bug tracker. thus, I don't want
to put misleading advertise. As far as our community don't have any
maintainer nor developer, we have to keep silence. I'm afraid
unnecessary
advertise bring them harmful.

Consider dropping the OS version as it's misleading and often out-of-date. For example, listing "Ubuntu 10.04 64bit" can be misinterpreted as meaning ruby-core is only supporting an outdated OS version. I know this to be false as I regularly test on Ubuntu 12.10 32bit and 64bit.

Instead of listing mingw, mswin32, mswin64 consider:

• Tier 1:

  • Windows 7/8 32/64bit (nobu)

• Tier 2:

  • Windows 7/8 32/64bit (usa)

Yes, I'm in favor of dropping "official" support for XP and ready to dodge the arrows for advocating for it ;)

Hm. this is interesting and debatable idea. I have an another idea.

• Tier 1:

  • Ubuntu 10.04 64-bit

• Tier 2:

  • Ubuntu >10.04 64-bit

The background theory is, tier1 must have CI. then tier have to have
version number. "maybe work" should be categorized tier 2.

[mame (Yusuke Endoh)]

• Subject changed from Let's decide Ruby 2.0 supported platform list to Let's decide Ruby 2.0 supported platform list

Thank you for your comments.

I've created a draft page of the supported list:
https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/20SupportedPlatforms

kosaki (Motohiro KOSAKI) wrote:

• Tier 1: the platform has a public CI (normally green) and is maintained by a ruby-core committer
• Tier 2: the platform is maintained by a ruby-core committer

I like a name of tier[12].

Agreed. The draft uses the names and descriptions. Thanks.

• 3rd Party: best-effort support by members of the ruby community (e.g. - https://fedoraproject.org/wiki/Ruby_SIG)

Note that the 3rd Party tier is an opportunity for commercial and non-commercial parties to get a form of (non-endorsed) advertisement.

While it should be self evident that just because a platform (e.g. Arch Linux) is not listed in any support tier doesn't mean MRI won't build/test/install on that platform, consider adding something much shorter than the sentence you just finished. Essentially, "try it, and if it breaks let us know."

In this case, 3rd party want to use their own bug tracker.

If the 3rd parties themselves want us to list the pointer on the list, it looks a good idea to provide the pointer to the bug tracker. May this just be harmful?

Consider dropping the OS version as it's misleading and often out-of-date. For example, listing "Ubuntu 10.04 64bit" can be misinterpreted as meaning ruby-core is only supporting an outdated OS version. I know this to be false as I regularly test on Ubuntu 12.10 32bit and 64bit.

Personally I agree.

Hm. this is interesting and debatable idea. I have an another idea.

• Tier 1:

  • Ubuntu 10.04 64-bit

• Tier 2:

  • Ubuntu >10.04 64-bit

The background theory is, tier1 must have CI. then tier have to have
version number. "maybe work" should be categorized tier 2.

It looks to me pedantic a little.
BTW: with regard to Ubuntu, I heard that Naruse-san plans to include Ubuntu 12.04 or 12.10 in Ruby CI.

--
Yusuke Endoh [e-mail]

[jonforums (Jon Forums)]

I've created a draft page of the supported list:
https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/20SupportedPlatforms

Suggested mods given ci.rubyinstaller.org currently has only win7 build slave(s):

Tier 1

• • mingw (nobu)
• • Windows 7/8 32/64bit (nobu)

• • Windows 7 32/64bit using mingw/mingw-w64 toolchain (nobu)

Tier 2

• • Windows 7/8 32/64bit (usa)

• • Windows 7/8 32/64bit using mswin toolchain (usa)

[luislavena (Luis Lavena)]

Actually:

• mingw (nobu)

Is more nobu, h.shirosaki and myself (luislavena) who care about Ruby be stable and compatible with MinGW/mingw-w64 projects.

[jonforums (Jon Forums)]

Actually:

• mingw (nobu)

Is more nobu, h.shirosaki and myself (luislavena) who care about Ruby be stable and compatible with MinGW/mingw-w64 projects.

Luis, are you saying the listing should look like this?

• Windows 7 32/64bit using mingw/mingw-w64 toolchain (nobu, shirosaki, lavena)

Is the idea to list

(a) a single committer who's ultimately responsible for the health of each specific platform even though other committers help to maintain the platform, or
(b) all committers who focus on keeping the platform stable?

Dne 10.2.2013 13:01, mame (Yusuke Endoh) napsal(a):

• 3rd Party: best-effort support by members of the ruby community (e.g. - https://fedoraproject.org/wiki/Ruby_SIG)

Note that the 3rd Party tier is an opportunity for commercial and non-commercial parties to get a form of (non-endorsed) advertisement.

While it should be self evident that just because a platform (e.g. Arch Linux) is not listed in any support tier doesn't mean MRI won't build/test/install on that platform, consider adding something much shorter than the sentence you just finished. Essentially, "try it, and if it breaks let us know."

In this case, 3rd party want to use their own bug tracker.
If the 3rd parties themselves want us to list the pointer on the list, it looks a good idea to provide the pointer to the bug tracker. May this just be harmful?

Speaking of Fedora, we would be happy to have Ruby SIG [1] listed on
Ruby's supported platform list. Ruby 2.0.0 is going to be supported
starting by Fedora 19 [2]. Please not that our support is primarily
targeted for RPM packaged Ruby, although we are happy to help Ruby users
on Fedora in general. Regarding the bug tracker, I would say that it is
common to Fedora users to report their issues in the first to the
Fedora's bug tracker, so I am not sure listing the Fedora's bugzilla in
the supported platform list would make any difference.

Vít

[1] https://fedoraproject.org/wiki/Ruby_SIG
[2] https://fedoraproject.org/wiki/Features/Ruby_2.0.0

[luislavena (Luis Lavena)]

On Sun, Feb 10, 2013 at 4:19 PM, Vít Ondruch [e-mail] wrote:

Dne 10.2.2013 13:01, mame (Yusuke Endoh) napsal(a):

Speaking of Fedora, we would be happy to have Ruby SIG [1] listed on Ruby's
supported platform list. Ruby 2.0.0 is going to be supported starting by
Fedora 19 [2]. Please not that our support is primarily targeted for RPM
packaged Ruby, although we are happy to help Ruby users on Fedora in
general. Regarding the bug tracker, I would say that it is common to Fedora
users to report their issues in the first to the Fedora's bug tracker, so I
am not sure listing the Fedora's bugzilla in the supported platform list
would make any difference.

Can Fedora provide a CI environment that send build reports to
rubyci.org? That why it could be considered as supported if it have
visibility.

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

Dne 10.2.2013 21:50, Luis Lavena napsal(a):

On Sun, Feb 10, 2013 at 4:19 PM, Vít Ondruch [e-mail] wrote:

Dne 10.2.2013 13:01, mame (Yusuke Endoh) napsal(a):

Speaking of Fedora, we would be happy to have Ruby SIG [1] listed on Ruby's
supported platform list. Ruby 2.0.0 is going to be supported starting by
Fedora 19 [2]. Please not that our support is primarily targeted for RPM
packaged Ruby, although we are happy to help Ruby users on Fedora in
general. Regarding the bug tracker, I would say that it is common to Fedora
users to report their issues in the first to the Fedora's bug tracker, so I
am not sure listing the Fedora's bugzilla in the supported platform list
would make any difference.

Can Fedora provide a CI environment that send build reports to
rubyci.org? That why it could be considered as supported if it have
visibility.

ruby-core:51056 still holds

Vít

[normalperson (Eric Wong)]

"mame (Yusuke Endoh)" [e-mail] wrote:

• maintained
  • CentOS5 (Eric Wong)

Sorry I can't guarantee much support for CentOS5 anymore.
I'm mainly using Debian 6/7 and CentOS6 nowadays.
Fortunately, the platforms are all still similar, and any
differences are likely to be in my recent memory :)

[yhara (Yutaka HARA)]

• Subject changed from Let's decide Ruby 2.0 supported platform list to Let's decide Ruby 2.0 supported platform list

[usa (Usaku NAKAMURA)]

Hello,

In message "[ruby-core:52116] [ruby-trunk - Bug #7820] Let's decide Ruby 2.0 supported platform list"
on Feb.11,2013 03:09:46, [e-mail] wrote:

Luis, are you saying the listing should look like this?

• Windows 7 32/64bit using mingw/mingw-w64 toolchain (nobu, shirosaki, lavena)

I'm not opposed to this, but I think the primary maintainer of mingw
should be luis, because nobu uses his time to other platforms now.
The development power of nobu is our common property, and luis and
his CI are the most important part for mingw now.

In addition, of course, I have not ignored shirosaki-san's contribution.
However, I understand that he mainly contributes in Windows' commin issues
rather than mingw's.

Regards,

U.Nakamura [e-mail]

[luislavena (Luis Lavena)]

On Wed, Feb 13, 2013 at 7:42 AM, U.Nakamura [e-mail] wrote:

Hello,

In message "[ruby-core:52116] [ruby-trunk - Bug #7820] Let's decide Ruby 2.0 supported platform list"
on Feb.11,2013 03:09:46, [e-mail] wrote:

Luis, are you saying the listing should look like this?

• Windows 7 32/64bit using mingw/mingw-w64 toolchain (nobu, shirosaki, lavena)

I'm not opposed to this, but I think the primary maintainer of mingw
should be luis, because nobu uses his time to other platforms now.
The development power of nobu is our common property, and luis and
his CI are the most important part for mingw now.

In addition, of course, I have not ignored shirosaki-san's contribution.
However, I understand that he mainly contributes in Windows' commin issues
rather than mingw's.

Hello,

Sorry for late response on this, got lost in my inbox.

Thank you Nakamura-san for the word of confidence.

I can take maintainer role of MinGW from Nobu.

So supported platforms:

• Windows 7 (32/64bits) using MinGW toolchains (mingw/mingw-w64) - luislavena

Regards,

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[mame (Yusuke Endoh)]

• Status changed from Assigned to Closed

Hello, thank you all for the feedback!

I updated:

https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/20SupportedPlatforms

• removed "DRAFT"

• multiple maintainers for one platform are allowed

  • added some people as a maintainer
  • set the first maintainer of mingw to luis

• added Haiku and NetBSD

• removed the platform versions (This is arguable, but I preferred the simplicity. I added the links to CIs for people who want to see the exact versions.)

• added a note that the list may change depending on the activity of the maintainer (Though it is not good to change support level after released, it is the fact that we cannot maintain the platform without the maintainer.)

Sorry if I missed anything.

I'm closing this ticket but feel free to continue to discuss support platform and maintainer. (It is difficult to reflect to 2.0.0, but the discussion will absolutely make 2.1.0 very good!)

Thank you!

--
Yusuke Endoh [e-mail]