Merge branch 'master' into patch-2

Author: hsbt

Gemfile.lock

@@ -34,13 +34,13 @@ GEM
       sassc (> 2.0.1, < 3.0)
     jekyll-watch (2.2.1)
       listen (~> 3.0)
-    json (2.6.1)
+    json (2.6.2)
     kgio (2.11.4)
-    kramdown (2.3.2)
+    kramdown (2.4.0)
       rexml
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
-    lanyon (0.4.3)
+    lanyon (0.4.4)
       jekyll (>= 2.0)
       rack (>= 1.6, < 3.0)
     liquid (4.0.3)
@@ -49,18 +49,18 @@ GEM
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.4.0)
     mini_portile2 (2.8.0)
-    minitest (5.15.0)
-    nokogiri (1.13.4)
+    minitest (5.16.2)
+    nokogiri (1.13.6)
       mini_portile2 (~> 2.8.0)
       racc (~> 1.4)
     nokogumbo (2.0.5)
       nokogiri (~> 1.8, >= 1.8.4)
     paint (2.2.1)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
-    public_suffix (4.0.6)
+    public_suffix (4.0.7)
     racc (1.6.0)
-    rack (2.2.3)
+    rack (2.2.4)
     rack-protection (2.2.0)
       rack
     rack-rewrite (1.5.1)
@@ -72,7 +72,7 @@ GEM
     rb-inotify (0.10.1)
       ffi (~> 1.0)
     rexml (3.2.5)
-    rouge (3.28.0)
+    rouge (3.29.0)
     safe_yaml (1.0.5)
     sassc (2.4.0)
       ffi (~> 1.9)

_data/downloads.yml

@@ -15,12 +15,10 @@ stable:
 # optional
 security_maintenance:
 
-  - 2.6.10
-
 # optional
 eol:
 
-  - 2.5.9
+  - 2.6.10
 
 stable_snapshots:
 
@@ -45,13 +43,6 @@ stable_snapshots:
       zip: https://cache.ruby-lang.org/pub/ruby/snapshot/snapshot-ruby_2_7.zip
     version: '2.7'
 
-  - branch: ruby_2_6
-    url:
-      gz: https://cache.ruby-lang.org/pub/ruby/snapshot/snapshot-ruby_2_6.tar.gz
-      xz: https://cache.ruby-lang.org/pub/ruby/snapshot/snapshot-ruby_2_6.tar.xz
-      zip: https://cache.ruby-lang.org/pub/ruby/snapshot/snapshot-ruby_2_6.zip
-    version: '2.6'
-
 nightly_snapshot:
 
   url:

_includes/analytics.html

@@ -78,7 +78,5 @@ <h2>{{ site.data.locales[page.lang].slogan }}</h2>
         {% include credits.html %}
       </div>
     </div>
-
-    {% include analytics.html %}
   </body>
 </html>

_layouts/default.html

@@ -33,4 +33,4 @@ lang: bg
 
 
 
-[meetup]: https://ruby.meetup.com
+[meetup]: https://www.meetup.com/topics/ruby/

bg/community/user-groups/index.md

@@ -4,144 +4,132 @@ title: "Ruby Core"
 lang: de
 ---
 
-Jetzt ist die beste Zeit, die weitere Entwicklung von Ruby zu verfolgen,
-denn Ruby 2.0 ist in Arbeit. Durch das erhöhte Interesse an Ruby,
-das sich in den letzten Jahren entwickelt hat, besteht ein
-steigender Bedarf an Talenten, die bei der Verbesserung von Ruby und der
-Dokumentation seiner Teile mitwirken. Also, womit willst Du anfangen?
+Jetzt ist die beste Zeit, die weitere Entwicklung von Ruby zu verfolgen.
+Durch das in den letzten Jahren gestiegene Interesse an Ruby besteht ein
+wachsender Bedarf an Talenten, die bei der Verbesserung von Ruby und der
+Dokumentation seiner Bestandteile mitwirken. Also, womit willst Du anfangen?
 {: .summary}
 
 Die hier behandelten Themen zur Entwicklung von Ruby sind Folgende:
 
-* [Subversion zur Entwicklung von Ruby nutzen](#following-ruby)
-* [Mit Git arbeiten](#git-ruby)
+* [Die Ruby-Entwicklung über Git verfolgen](#following-ruby)
 * [Ruby verbessern, Patch für Patch](#patching-ruby)
-* [Regeln für Core-Entwickler](#coding-standards)
+* [Hinweis zu Branches](#branches-ruby)
 
-### Subversion zur Entwicklung von Ruby nutzen
+### Die Ruby-Entwicklung über Git verfolgen
 {: #following-ruby}
 
-Mit dem folgenden Kommandozeilenbefehl kannst du den aktuellsten
-Quelltext von Ruby über Subversion herunterladen (auschecken):
+Das aktuelle Haupt-Repository mit dem neuesten Ruby-Quellcode ist
+[git.ruby-lang.org/ruby.git][gitrlo].
+Zusätzlich existiert auch ein [Mirror auf GitHub][7].  Verwende im Allgemeinen bitte diesen Mirror.
+
+Du kannst über Git den neuesten Quellcode von Ruby beziehen.
+Von deiner Kommandozeile:
 
 {% highlight sh %}
-$ svn co https://svn.ruby-lang.org/repos/ruby/trunk ruby
+$ git clone https://github.com/ruby/ruby.git
 {% endhighlight %}
 
-Das Verzeichnis `ruby` enthält nun den vollständigen Quelltext der
-Entwicklerversion Ruby 1.9. Bitte bedenke, dass es sich bei dieser
-Version um die absolut neuste Variante von Ruby handelt. Sie wird
-ständig weiterentwickelt und wird erst am Ende des Jahres 2007 offiziell
-veröffentlicht.
+Der Ordner `ruby` wird jetzt den neuesten Quellcode für die Entwicklungsversion von Ruby beinhalten (ruby-trunk).
+
+Siehe dazu auch das Dokument [Non-committer’s HOWTO to join our development][noncommitterhowto].
 
-Wenn du Interesse an der Verbesserung von Ruby 1.8 hast, solltest du dir
-den Branch `ruby_1_8` genauer anschauen. Über den folgenden
-Kommandozeilenbefehl kannst du den Quelltext auschecken:
+Wenn du Commit-Berechtigung hast und etwas pushen möchtest, solltest du
+das Haupt-Repository verwenden.
 
 {% highlight sh %}
-$ svn co https://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8
+$ git clone git@git.ruby-lang.org:ruby.git
 {% endhighlight %}
 
-Damit hast du die aktuelle Entwicklerversion des offiziellen Ruby 1.8
-Zweiges in das Verzeichnis `ruby_1_8` heruntergeladen. Entwickler, die
-einen Patch für diese Version entwickeln, werden darum gebeten ebenfalls
-einen Patch für die Entwicklerversion 1.9 zu erstellen. Aufgrund dessen
-sollten die Versionen 1.8 und 1.9 sich einander ähneln, mit der Ausnahme
-von Erweiterungen an der Sprache Ruby selbst.
+### Ruby verbessern, Patch für Patch
+{: #patching-ruby}
 
-Bei Interesse besteht die Möglichkeit das [Ruby-Repository über den
-Webbrowser][1] zu begutachten.
+Das Kernteam betreibt einen [Issue-Tracker][10] für das Beisteuern von Patches
+und Fehlerberichte an Matz und die Gang. Diese Berichte werden auch an die [Ruby-Core Mailingliste][mailing-lists] zur Diskussion gesendet. So kannst du
+sicher sein, dass deine Anfrage nicht unbemerkt bleibt.
+Du kannst Patches auch direkt an die Mailingliste senden. Wie auch immer,
+du bist herzlich eingeladen an der entstehenden Diskussion teilzunehmen.
 
-Für weiterführende Informationen bezüglich Subversion bietet sich die
-englischsprachige [Subversion-FAQ][2] und das ebenfalls
-englischsprachige [Subversion-Buch][3] an.
+Bitte schau dir den [Leitfaden für Patch-Autoren][writing-patches] an.
+Dort findest du einige Tips direkt von Matz dazu, wie deine Patches berücksichtigt werden können.
 
-### Mit Git arbeiten
-{: #git-ruby}
+Als Zusammenfassung, die Schritte zur Erstellung eines Patches sind:
 
-Diejenigen, die [Git][4] bevorzugen, können einen [Mirror auf GitHub][5]
-nutzen. Dieser kann von [offiziellen Committern][6] und [allen
-Anderen][7] benutzt werden.
+1.  Checke den Ruby-Quellcode von GitHub aus.
+    Patches für Bugfixes oder neue Features sollten für den `trunk` von
+    Rubys Quellcode abgegeben werden.
 
-### Ruby verbessern, Patch für Patch
-{: #patching-ruby}
+        $ git clone https://github.com/ruby/ruby.git
 
-Rubyforge bietet einen [Bug-Tracker][8] für das Melden von Fehlern und
-Übersenden von Patches an Matz und die Anderen. Die Fehlerreports gehen
-parallel auch zur Diskussion an die Ruby-Core-Mailingliste, wodurch keine
-Fehlermeldung unbeachtet bleibt.
+    Wenn du einen Bug in einem Maintenance-Branch fixen willst, dann checke
+    eine Kopie dieses Branches aus.
 
-Zusammenfassend sind folgende Schritte für das Erstellen eines Patches
-erforderlich:
+        $ git checkout ruby_X_X
 
-1.  Eine Kopie von Ruby 1.8 auschecken. Dabei das Tag
-    `ruby_1_8` verwenden.
+    X_X sollte durch die auszucheckende Version ersetzt werden.
 
-         $ cvs -z4 -d :pserver:anonymous@cvs.ruby-lang.org:/src \
-             co -r ruby_1_8 -d ruby-1.8 ruby
+2.  Füge deine Verbesserungen zum Code hinzu.
 
-2.  Hinzufügen der eigenen Verbesserungen (im Verzeichnis `ruby-1.8`).
-3.  Einen Patch erstellen.
+3.  Erstelle einen Patch.
 
-         $ cvs diff > ruby-1.8-changes.patch
+        $ git diff > ruby-changes.patch
 
-4.  [Abschicken][9] des neuen Patches.
+4.  Erstelle ein Ticket im [Issue-Tracker][10] oder maile deinen Patch an
+    die [Ruby-Core Mailingliste][mailing-lists] mit einem ChangeLog-Eintrag
+    zu deinem Patch.
 
-**Bitte beachten:** Patches sollten als [unified diff][10] abgeschickt
-werden. Wer mehr über das Zusammenführen (Merge) der Patches wissen will,
-sollte sich die [diffutils-Referenz][11] ansehen.
+5.  Wenn zu dem Patch keine Bedenken angemeldet werden, dann wird den
+    Committern die Berechtigung erteilt, ihn zu übernehmen.
 
-Diskussionen zum Thema Ruby-Entwicklung werden in der
-[Ruby-Core-Mailingliste][mailing-lists] gebündelt.
-Wer herausfinden will, ob sein Patch Sinn macht oder nur eine Diskussion
-über die Zukunft von Ruby anfangen will, sollte nicht zögern an Bord zu
-kommen. Es wird an dieser Stelle davor gewarnt, Off-Topic Diskussionen
-zu führen, da diese in der Liste nicht akzeptiert werden. Es sollte klar
-kommuniziert und aussagekräftige Überschriften verwendet werden.
-Schließlich wird hier der Erfinder von Ruby angesprochen, daher lasst
-uns ein wenig Respekt haben.
+**Bitte beachte:** Patches sollten als [unified diff][12] abgegeben werden.
+Siehe [die diffutils Referenz][13] für mehr Informationen dazu, wie Patches übernommen werden.
 
-Es sollte klar sein, dass das Kernteam in Japan lebt. Obwohl die meisten
-sehr gut Englisch sprechen, gibt es aber auch noch einen signifikanten
-Unterschied in der Zeitzone zu beachten. Es existieren übrigens auch
-komplett japanischsprachige Listen neben den englischen Pendants. Man
-sollte nur die Ruhe bewahren, wenn eine Antwort nicht sofort
-zurückkommt. Notfalls kann die gleiche Anfrage ein paar Tage später
-nochmal gestellt werden.
+Die Diskussion zur Ruby-Entwicklung findet auf der
+[Ruby-Core Mailingliste][mailing-lists] statt. Wenn du also neugierig bist,
+ob sich dein Patch lohnt oder du eine Diskussion zur Zukunft von Ruby
+starten möchtest, dann zögere nicht, an Bord zu kommen.
+Sei gewarnt: Off-Topic-Diskussionen werden auf dieser Liste nicht toleriert.
+Der Lärmpegel sollte niedrig, Themen sollten pointiert, gut durchdacht
+und formuliert sein. Da wir uns an den Schöpfer von Ruby wenden, sollten
+wir etwas Ehrfurcht an den Tag legen.
 
-### Regeln für Core-Entwickler
-{: #coding-standards}
+Behalte im Hinterkopf, dass viele Kernentwickler von Ruby in Japan leben.
+Viele sprechen hervorragendes Englisch, aber trotzdem bleibt ein erheblicher
+Zeitzonen-Unterschied.
+Außerdem gibt es neben den englischen auch eine ganze Menge japanische Entwicklungs-Mailinglisten. Sei geduldig. Wenn deine Anfrage nicht gelöst wird,
+dann bleib dran - versuch es ein paar Tage später nochmal.
 
-Allgemein sollten Entwickler von Ruby mit den Quelltexten und dem
-Entwicklungstil des Teams vertraut sein. Zum besseren Verständnis
-sollten die folgenden Richtlinien beim Einchecken ins
-Subversion-Repository beachtet werden:
+### Hinweis zu Branches
+{: #branches-ruby}
+
+Der Ruby-Quellcode wurde bis zum 22. April 2019 über Subversion verwaltet.
+Daher werden manche Zweige immer noch über Subversion gepflegt.
+Du kannst das SVN-Repository betrachten.
+
+* [<URL:https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?root=ruby>][svn-viewvc]
+
+Normalerweise musst du dich darum aber nicht kümmern (außer wenn du ein
+Branch-Maintainer bist).
+Du kannst Branches in deiner Git-Arbeitskopie auschecken,
+zum Beispiel über folgendes Kommando.
+
+{% highlight sh %}
+$ git checkout ruby_X_X
+{% endhighlight %}
 
-* Alle Änderungen sollten im `ChangeLog` gemäß den
-  [GNU-Konventionen][12] erfasst werden. (Viele Core-Entwickler von Ruby
-  nutzen den `add-log` Modus von Emacs: `C-x 4 a`.)
-* Der Check-in Zeitstempel sollte in Japan Standard Time (UTC+9)
-  angegeben werden.
-* Die Punkte im ChangeLog sollten als Kommentar beim Einchecken
-  verwendet werden. Dieser Kommentar wird automatisch nach einem Commit
-  an die Ruby-CVS-Liste gemailt.
-* Funktionsprototypen werden überall im Ruby-Quelltext verwendet.
-* Bitte keine C++-Kommentare (`//`) verwenden. Das Ruby-Wartungsteam
-  bevorzugt stattdessen die Mehrzeilenkommentare von Standard-C
-  (`/* .. */`).
+X_X sollte durch die auszucheckende Version ersetzt werden.
 
+Wenn du die Zweige modifizieren möchtest, dann öffne bitte ein Issue im
+[Issue-Tracker][10].
+Siehe auch den nachfolgenden Abschnitt.
 
 
+[gitrlo]: https://git.ruby-lang.org/ruby.git
 [mailing-lists]: /de/community/mailing-lists/
-[1]: https://svn.ruby-lang.org/cgi-bin/viewvc.cgi/
-[2]: http://subversion.apache.org/faq.html
-[3]: http://svnbook.org
-[4]: http://git-scm.com/
-[5]: https://github.com/ruby/ruby
-[6]: https://github.com/shyouhei/ruby/wiki/committerhowto
-[7]: https://github.com/shyouhei/ruby/wiki/noncommitterhowto
-[8]: http://rubyforge.org/tracker/?func=browse&group_id=426&atid=1698
-[9]: http://rubyforge.org/tracker/?func=add&group_id=426&atid=1700
-[10]: http://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html
-[11]: http://www.gnu.org/software/diffutils/manual/html_node/Merging-with-patch.html#Merging%20with%20patch
-[12]: http://www.gnu.org/prep/standards/standards.html#Change-Logs
+[writing-patches]: /de/community/ruby-core/writing-patches/
+[noncommitterhowto]: https://github.com/shyouhei/ruby/wiki/noncommitterhowto
+[svn-viewvc]: https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?root=ruby
+[7]: https://github.com/ruby/ruby
+[10]: https://bugs.ruby-lang.org/
+[12]: http://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html
+[13]: http://www.gnu.org/software/diffutils/manual/html_node/Merging-with-patch.html#Merging%20with%20patch

de/community/ruby-core/index.md

@@ -0,0 +1,50 @@
+---
+layout: page
+title: "Leitfaden für Patch-Autoren"
+lang: de
+---
+
+Hier findest du einige Tips direkt von Matz dazu, wie deine Patches berücksichtigt werden können.
+{: .summary}
+
+Diese Richtlinien wurden von einem [Post von Matz][ruby-core-post]
+auf der Ruby-Core Mailingliste übernommen und angepasst:
+
+* Implementiere eine Änderung pro Patch
+
+  Das ist das größte Hindernis für die meisten verzögerten Patches.
+  Wenn du einen Patch sendest, der gleichzeitig mehrere Bugs behebt
+  (und Features hinzufügt), dann müssen wir sie vor der Übernahme auftrennen.
+  Das ist für uns geschäftige Entwickler eine mühsame Aufgabe.
+  Daher werden solche Patches oft verzögert. Bitte keine großen Patches.
+
+* Liefere Beschreibungen
+
+  Manchmal beschreibt ein bloßer Patch das gelöste Problem nicht hinreichend.
+  Eine bessere Beschreibung (das behobene Problem, Vorbedigungen, Plattform
+  etc.) würde für eine zügige Übernahme helfen.
+
+* Verwende die aktuellste Revision
+
+  Dein Problem könnte in der aktuellsten Revision bereits gelöst sein.
+  Oder der Code ist dort vielleicht bereits völlig anders.
+  Vor dem Senden eines Patches solltest du bitte die aktuellste Version laden
+  (der `trunk` Branch für die neueste Entwicklungsversion,
+  `{{ site.svn.stable.branch }}` für {{ site.svn.stable.version }}) aus dem Subversion-Repository.
+
+* Verwende `diff -u`
+
+  Wir verwenden lieber `diff -u` Unified-Diff-Patches als `diff -c` oder
+  andere Patchformate. Diese sind viel leichter zu begutachten.
+  Sende keine ganzen modifizierten Dateien, denn wir wollen nicht selbst einen
+  Diff erstellen.
+
+* Liefere Test-Cases (optional)
+
+  Ein Patch mit Test-Cases (vorzugsweise ein Patch zu `test/*/test_*.rb`)
+  würde uns helfen, den Patch und deine Absicht besser zu verstehen.
+
+In Zukunft wechseln wir vielleicht auf einen Git-Workflow mit Pull-Requests.
+Aber bis dahin wird das Befolgen dieser Richtlinien Frustration vermeiden.
+
+[ruby-core-post]: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/25139

de/community/ruby-core/writing-patches/index.md

@@ -81,7 +81,7 @@ deutschsprachigen Artikeln. Für weitergehende Fragen steht eine große
 [8]: http://www.approximity.com/rubybuch2/
 [9]: http://www.ruby-doc.org/core
 [10]: http://www.ruby-doc.org/stdlib
-[extensions]: https://docs.ruby-lang.org/en/master/doc/extension_rdoc.html
+[extensions]: https://docs.ruby-lang.org/en/master/extension_rdoc.html
 [12]: http://www.rubydoc.info/
 [13]: http://ruby-doc.org
 [14]: http://wiki.ruby-portal.de