https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112018-12-29T18:32:27ZRuby Issue Tracking SystemRuby master - Misc #15487: Clarify default gems maintanance policyhttps://redmine.ruby-lang.org/issues/15487?journal_id=759902018-12-29T18:32:27Zmarcandre (Marc-Andre Lafortune)marcandre-ruby-core@marc-andre.ca
<ul></ul><p>Much of this is in this <a href="https://github.com/ruby/ruby/blob/trunk/doc/maintainers.rdoc" class="external">list of maintainers</a> and <a href="https://bugs.ruby-lang.org/projects/ruby/wiki/MaintainerDischargingProcess" class="external">basic maintainers guidelines</a></p>
<p>As for the <code>json</code> gem, I agree it should be made clear which is the authoritative repository. I can help with maintainership too.</p> Ruby master - Misc #15487: Clarify default gems maintanance policyhttps://redmine.ruby-lang.org/issues/15487?journal_id=759922018-12-29T23:19:22Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>hsbt (Hiroshi SHIBATA)</i></li></ul><p><code>json</code> is not a good example of default gems. Because I and nalsh got the only commit bit of <code>flori/json</code> at recently, not release a grant of rubygems.org.</p> Ruby master - Misc #15487: Clarify default gems maintanance policyhttps://redmine.ruby-lang.org/issues/15487?journal_id=759972018-12-30T00:18:38Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>Some of libraries has upstream and others are originated in ruby repo.<br>
And some upstreams are not maintained but some of such libraries are transfered its privilege to hsbt.</p>
<p>Such historical reasons are hard to explain.<br>
OSS project depends on volunteer and explanation itself takes much cost.<br>
Read doc/maintainers.rdoc and logs of mailing list and related issues.</p>
<p>Anyway just about json.gem, you should imagine what the conclusion will be.</p> Ruby master - Misc #15487: Clarify default gems maintanance policyhttps://redmine.ruby-lang.org/issues/15487?journal_id=760132018-12-30T20:42:22Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/5">@naruse (Yui NARUSE)</a> Sorry if my original request was sounding too aggressive, just stating "something is wrong" is never my intention.</p>
<blockquote>
<p>Such historical reasons are hard to explain.</p>
</blockquote>
<p>Yes, I understand that.</p>
<blockquote>
<p>OSS project depends on volunteer and explanation itself takes much cost.</p>
</blockquote>
<p>I understand that too. That's the <em>exact</em> 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.</p>
<p>My current "main" work for Ruby is <a href="https://rubyreferences.github.io/rubyref/" class="external">The Ruby Reference</a>, 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).</p>
<p>So, going towards more practical matters, I am thinking about this:</p>
<ul>
<li>
<code>contributing.rdoc</code>: add "Contributing to default gems" section, which should explain:
<ul>
<li>that default gems "master" source is on GitHub, and just copied back to Ruby before release;</li>
<li>where are API changes discussed</li>
<li>what are general policies of default gem changes</li>
</ul>
</li>
<li>
<code>maintainers.rdoc</code>:
<ul>
<li>add missing links to GitHub repositories</li>
<li>explain what does it mean "unmaintained"</li>
<li>clearly state problematic repositories (if any), like <code>json</code>, where Ruby maintainers can't commit to the library, actually</li>
</ul>
</li>
<li>Gem's docs: add links back to aforementioned policies, or reinclude their text.</li>
</ul>
<p>So, my real questions are:</p>
<ol>
<li>First and most important: would it be welcomed if I'll contribute the texts as described above?</li>
<li>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.</li>
<li>Are there any parts of the standard library that are "implicitly retired"? (In some discussions, <code>date</code> seemed so?) Meaning they are not removed for backward compatibility, but they should be considered rather "frozen" (no new features anticipated or welcomed).</li>
<li>What does "unmaintained" in <code>maintainers.rdoc</code> mean? If, say, I'd like to change something about <code>date</code>, there wouldn't anybody to discuss/merge/review it?.. Isn't it necessary to call to community for a new maintainers?</li>
<li>What's current status of maintenance for <code>json</code> gem? Would it be moved to <code>ruby</code> organization at some point? Are there any other default gems with similar "complicated" status?</li>
</ol>
<p>I will be happy with short/informal/incomplete answers and ready to approach the problem in an iterative manner.</p>