[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
naruse@airemix.jp wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <headius@headius.com> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
k0kubun@ruby-lang.org wrote:
3 messages
2018/12/30
[ruby-core:90830] [Ruby trunk Misc#15487] Clarify default gems maintanance policy
From:
zverok.offline@...
Date:
2018-12-30 20:42:25 UTC
List:
ruby-core #90830
Issue #15487 has been updated by zverok (Victor Shepelev). @naruse Sorry if my original request was sounding too aggressive, just stating "something is wrong" is never my intention. > Such historical reasons are hard to explain. Yes, I understand that. > OSS project depends on volunteer and explanation itself takes much cost. I understand that too. That's the _exact_ reason I am asking: I'll gladly volunteer to improve the documentation and add missing one, I just want to have a deeper understanding of the matters. My current "main" work for Ruby is [The Ruby Reference](https://rubyreferences.github.io/rubyref/), and working on it had already proven to be a source of some insights (you can look into my recent contributions to docs of core classes, which was sourced exactly from compiling The Reference). So, going towards more practical matters, I am thinking about this: * `contributing.rdoc`: add "Contributing to default gems" section, which should explain: * that default gems "master" source is on GitHub, and just copied back to Ruby before release; * where are API changes discussed * what are general policies of default gem changes * `maintainers.rdoc`: * add missing links to GitHub repositories * explain what does it mean "unmaintained" * clearly state problematic repositories (if any), like `json`, where Ruby maintainers can't commit to the library, actually * Gem's docs: add links back to aforementioned policies, or reinclude their text. So, my real questions are: 1. First and most important: would it be welcomed if I'll contribute the texts as described above? 2. The main place for discussing new features: is it this tracker or GitHub issues? (I've seen statements from different maintainers claiming one or another, for different gems). It is probably OK if it is different for different gems, but also should be documented. 3. Are there any parts of the standard library that are "implicitly retired"? (In some discussions, `date` seemed so?) Meaning they are not removed for backward compatibility, but they should be considered rather "frozen" (no new features anticipated or welcomed). 4. What does "unmaintained" in `maintainers.rdoc` mean? If, say, I'd like to change something about `date`, there wouldn't anybody to discuss/merge/review it?.. Isn't it necessary to call to community for a new maintainers? 5. What's current status of maintenance for `json` gem? Would it be moved to `ruby` organization at some point? Are there any other default gems with similar "complicated" status? I will be happy with short/informal/incomplete answers and ready to approach the problem in an iterative manner. ---------------------------------------- Misc #15487: Clarify default gems maintanance policy https://bugs.ruby-lang.org/issues/15487#change-76013 * Author: zverok (Victor Shepelev) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- In addition to #15486, I'd like to raise the question of the general _maintanance policy_ for "default" Ruby gems, in particular: * who is responsible for each gem and how they should be contacted? * what are goals and policies for gems code quality and documentation? * where do default gems are discussed? * what are some promises/guarantees default gems maintainers try to fulfill? The most demonstrative example I'd like to point is `json` gem: * The source at [ruby/json](https://github.com/ruby/json) is NOT authoritative as far as I can tell, the authoritative one is [flori/json](https://github.com/flori/json) * The gem still holds signs of the times it was independent (`Pure` and `Ext` JSON implementations, but `Pure` is not copied into the `ruby/lib` on releases, rendering standard docs pretty weird), and has NO mention it is THE json gem of Ruby * The gem seems unmaintained, considering the amount of [PRs](https://github.com/flori/json/pulls) and [issues](https://github.com/flori/json/issues), lot of them without any reaction for months * When I tried to update JSON docs, in [core tracker issue](https://bugs.ruby-lang.org/issues/14581) I was asked to make a PR to "upstream repository", but there, the PRs ([#347](https://github.com/flori/json/pull/347), [#349](https://github.com/flori/json/pull/349)) was simply ignored; Ruby 2.6 was released without new docs, despite the fact PRs were made at **March** and require almost no code review (unlike even some promising optimization PRs, that were also hanging there since Feb/Mar) It is just one unfortunate case (TBH, my experience with contributing to other libraries, like `csv` and `psych` was much smoother), but it demonstrates some common lack of transparency in maintaining of Ruby's standard library -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>