Beitrag zu OpenXLA

Jeder kann einen Beitrag zu OpenXLA leisten und wir schätzen die Beiträge aller. Es gibt verschiedene Möglichkeiten, einen Beitrag zu leisten:

  • Beantworten von Fragen in den Diskussionsforen von OpenXLA (openxla-discuss)

  • Verbessern oder Erweitern der OpenXLA-Dokumentation

  • Einen Beitrag zur Codebasis von OpenXLA leisten

  • Beitrag zu einer der oben genannten Möglichkeiten zum größeren Ökosystem von auf OpenXLA basierenden Bibliotheken

Das OpenXLA-Projekt entspricht den Open-Source-Community-Richtlinien von Google.

Hinweis

Contributor-Lizenzvereinbarung unterzeichnen

Alle Beiträge zu diesem Projekt müssen von einer Lizenzvereinbarung für Beitragende begleitet werden. Sie (oder Ihr Arbeitgeber) behalten das Urheberrecht an Ihrem Beitrag. Dies gibt uns lediglich die Berechtigung, Ihre Beiträge im Rahmen des Projekts zu verwenden und weiterzugeben.

Wenn Sie oder Ihr aktueller Arbeitgeber bereits das CLA von Google unterzeichnet haben (auch wenn es für ein anderes Projekt war), müssen Sie es wahrscheinlich nicht noch einmal tun.

Unter <https://cla.developers.google.com/> können Sie Ihre aktuellen Vereinbarungen einsehen oder eine neue Vereinbarung unterzeichnen.

Verhaltenskodex lesen

Dieses Projekt folgt dem Verhaltenskodex von Tensorflow.

Spendenvorgang

Entwicklerleitfaden

Eine Anleitung zum Einrichten einer Entwicklungsumgebung für OpenXLA, u. a. zum Abrufen von Code, Erstellen, Ausführen von Tests und Senden von Änderungen, finden Sie im Entwicklerleitfaden.

Code standards

  • Programmierstil: Wir halten uns an den Styleguide für Code von Google. Weitere Informationen finden Sie in den Leitfäden zu C/C++ und Python. Sämtlicher übermittelter Code muss genau diesen Styleguides entsprechen.

  • Kompakte Änderungen: Wir halten uns an die Entwicklungspraktiken von Google. Beachten Sie insbesondere den Leitfaden zum Schreiben kompakter Änderungen. Dadurch lässt sich der Code viel schneller zusammenführen, da die Überprüfbarkeit verbessert und die Wahrscheinlichkeit unbeabsichtigter Nebenwirkungen von Änderungen verringert wird. Auch wenn Sie eine große Änderung vornehmen, gibt es viele Strategien, um sie in mehrere inkrementelle Änderungen aufzuteilen.

  • Testabdeckung: Alle Änderungen sollten entsprechende Einheitentests enthalten. Einheitentests sollten nicht von bestimmten Timings der Hardware (CPU, GPU usw.) abhängen und Simulationen und Fälschungen frei verwenden, um deterministische und fokussierte Tests durchzuführen. Wenn Sie vorhandenen Code erweitern möchten, der derzeit schwer zu testen ist, sollten Sie die Testbarkeit entsprechend verbessern.

    Alle Änderungen sollten entsprechende Benchmarkergebnisse sowie im Titel der Änderung enthalten sein, damit die Vorteile klar verständlich sind.

  • Wenn Sie Zweifel an den Konventionen innerhalb des Codes haben, ist es immer eine gute Idee, bereits vorhandenen Code zu untersuchen und zu versuchen, den bereits in OpenXLA vorhandenen Mustern zu folgen.

Überprüfungsprozess

Alle Einreichungen, auch von Projektmitgliedern, müssen geprüft werden. Zu diesem Zweck verwenden wir GitHub-Pull-Anfragen. Weitere Informationen zur Verwendung von Pull-Anfragen finden Sie in der GitHub-Hilfe.

  • Der Code muss vor der Überprüfung allen oben aufgeführten Standards entsprechen. Diese sind nicht optional. Der Absender muss darauf achten, dass sein Code den Richtlinien entspricht, bevor er eine Überprüfung beantragt. Nur so kann eine zeitnahe Annahme der Änderungen sichergestellt werden.

  • Alle Tests müssen bestanden werden. Wenn Sie feststellen, dass ein Test fehlerhaft ist und das Problem nicht mit Ihrer Build-Umgebung oder Ihren Änderungen zusammenhängt, wenden Sie sich an die Administratoren.

  • Versuchen Sie, eine schleichende Erweiterung des Projektumfangs während des Überprüfungsprozesses zu vermeiden. Für diese Aufgabe sind sowohl der Beschwerdeführer als auch der prüfende Person verantwortlich. Wenn eine Änderung zu groß wird, sollten Sie sie in mehrere Änderungen aufteilen.

  • Bevor eine Änderung zusammengeführt wird, wird sie internen Tests unterzogen, bei denen interner Code für Google und andere Hardwareanbieter verwendet wird. Dies kann den Überprüfungsprozess um zusätzliche Schritte ergänzen, wenn bei internen Tests Fehler auftreten, die von unserem öffentlichen CI nicht erkannt werden. Der Google-Mitarbeiter, der Ihre Änderung überprüft, teilt Ihnen alle internen Testfehler mit und beschreibt, was behoben werden muss.

FAQ

Das XLA-Team hat kein eigenes Infrastrukturteam. Daher müssen wir alle Hilfsbibliotheken erstellen und technische Schulden vermeiden. Wir betrachten dies als regelmäßiger Bestandteil von Änderungen an XLA und es wird von allen erwartet, dass sie sich einbringen. In der Regel bauen wir die Infrastruktur nach Bedarf, wenn wir Code schreiben.

XLA-Prüfer können dich zusammen mit einem von dir verfassten PR bitten, eine Infrastruktur zu erstellen oder anderweitig eine große Änderung an einem PR vorzunehmen. Diese Anfrage kann für die Änderung, die Sie vornehmen möchten, unnötig oder orthogonal erscheinen. Dies liegt wahrscheinlich an einer Diskrepanz zwischen Ihren Erwartungen in Bezug auf die Infrastruktur, die Sie aufbauen müssen, und den Erwartungen des Rezensenten an diese.

Nicht übereinstimmende Erwartungen sind in Ordnung! Das ist zu erwarten, wenn Sie neu in einem Projekt sind (und manchmal passiert es auch mit alten Hüten). Wahrscheinlich haben Projekte, an denen Sie in der Vergangenheit gearbeitet haben, andere Erwartungen haben. Das ist auch in Ordnung und erwartungsgemäß! Das bedeutet nicht, dass eines dieser Projekte den falschen Ansatz verfolgt. Die Projekte sind nur unterschiedlich. Wir laden Sie ein, Infrastrukturanfragen zusammen mit allen anderen Kommentaren zu beantworten, um zu erfahren, was wir von diesem Projekt erwarten.

„Darf ich bei einem zukünftigen PR auf deinen Kommentar eingehen?“

Eine häufige Frage im Zusammenhang mit Infrastrukturanfragen (oder anderen großen Anfragen) in PRs ist, ob die Änderung im ursprünglichen PR vorgenommen werden muss oder ob dies als Folgefrage in einem zukünftigen PR erfolgen kann.

Im Allgemeinen ist es in XLA nicht erlaubt, PR-Autoren auf Kommentare von Rezensionen mit einer Follow-up-PR zu reagieren. Wenn ein Prüfer entscheidet, dass etwas in einer bestimmten PR behandelt werden muss, erwarten wir im Allgemeinen, dass die Autoren das in dieser PR angehen, auch wenn es sich um eine größere Änderung handelt. Dieser Standard gilt extern und auch intern innerhalb von Google.

Es gibt mehrere Gründe, warum XLA diesen Ansatz verfolgt.

  • Vertrauen:Das Vertrauen des Prüfers ist eine wichtige Komponente. In einem Open-Source-Projekt können Mitwirkende nach Belieben ein- oder ausgeblendet werden. Nachdem wir eine PR genehmigt haben, können die Prüfer nicht mehr dafür sorgen, dass die versprochenen Nachfragen tatsächlich durchgeführt werden.

  • Auswirkungen auf andere Entwickler:Wenn du eine PR gesendet hast, die einen bestimmten Teil von XLA betrifft, ist es sehr wahrscheinlich, dass andere Nutzer dasselbe sehen. Wenn wir technische Altlasten in Ihrer PR akzeptieren, sind alle, die sich diese Datei ansehen, von diesen Schulden betroffen, bis die weitere Überprüfung eingereicht wird.

  • Bandbreite der Prüfer:Das Zurückstellen einer Änderung bei einer Nachbearbeitung bringt unseren bereits überlasteten Prüfern mehrere Kosten mit sich. Während die Prüfer auf die Nachfrage warten, werden sie wahrscheinlich vergessen, worum es bei der ersten PR ging. Dadurch wird die nächste Überprüfung erschwert. Die prüfenden Personen müssen auch die erwarteten Follow-ups verfolgen, um sicherzustellen, Wenn die Änderung so vorgenommen werden kann, dass sie wirklich orthogonal zum ursprünglichen PR ist, sodass ein anderer Prüfer sie überprüfen könnte, wäre die Bandbreite weniger ein Problem. Nach unserer Erfahrung ist das selten der Fall.