Hallo Jonas, Uwe, Harald und Listlinge, Jonas Antwort finde ich hervorragend und die Vorgehensweise absolut empfehlenswert.
Ich habe mich in der Vergangenheit mit pull-requests sehr zurückgehalten, d.h. bisher genau zwei gemacht. Als ich zu einem I2C Kram einen stellte, erhielt ich keine Antwort. Ist mir egal, wenn sie es nicht wollen, ich habs für mich gemacht und: Works for me. Als ich (fürs THW) Taktische Zeichen auf einem Clone erstellt hatte, sandte ich einen Pull Request. Antwort war: Da sind Inkscape-Relikte drin, das nehm ich nicht. Also hab ich diese auch noch (alles Handarbeit mit Versuch und Irrtum) entfernt und den Pull Request erneuert. Antwort: keine. Dies scheint die Standard-Methode zu sein, die ich jedoch nicht gut finde und niemandem empfhelen kann. Ein Pullrequest zeigt doch, dass sich jemand mit dem Kram beschäftigt hat und er dazu beitragen möchte. Dann ist Jonas' Vorgehensweise genau richtig, finde ich. Haltet Abstand und bleibt gesund! Frohes Schaffen Johannes On 4/26/20 14:06, Jonas Stein wrote: > Hallo Harald, > >> Was würdet ihr machen, wenn ihr zu einem von euch auf Github eingestellten >> Projekt ohne vorherige Ankündung von einem bisher unbekannten User einen Pull >> Request bekommt? > > Das erlebe ich sehr häufig. Ich freue mich dann erst einmal. > Eine Vorankündigung habe ich nur ganz selten bekommen (< 10 mal). > > Die einen waren unsicher, die anderen wollten einen sehr > arbeitsaufwändigen Umbau vornehmen und das erst besprechen. > >> Der Request führt mehrere thematisch unterschiedliche Änderungen >> ein. Einen Teil davon möchte ich definitiv nicht übernehmen. Bei einem >> anderen >> sehe ich prinzipiell die Notwendigkeit einer Änderung, aber es gibt mehrere >> denkbare Optionen und ich bin noch unschlüssig. Der vom Sourcecode-Umfang her >> größte Teil ist durchaus in Ordnung, müsste allerdings noch ein bisschen >> überarbeitet werden, außerdem wurde bei der Dokumentation geschlampt. Der >> Pull >> Request besteht aus einem einzelnen Commit mit allen Änderungen, ein >> Cherry-Picking >> im Git-Sinne ist nicht möglich. > > Ich würde den PR kommentieren mit folgenden Hinweisen. > 0) Danken > 1) Bitte um einen Commit pro thematischer Änderung > 2) Beschreiben, was in einem Commit gemerged werden soll (der Teil der > durch kommt) > 3) Beschreiben, was hat noch Diskussionsbedarf; gebe die Commits vor, in > den Commits kann dann einzeln diskutiert / abgelehnt werden. > > > Das hat den Vorteil, dass man jemanden anlernt auch noch weitere PRs > nutzbingend vorzubereiten. > > Wenn keine Antwort mehr folgt kannst Du die Änderungen als patch > herunterladen und anpassen. > > Wenn ich bei Gentoo so eine Situation habe, sieht das z.B. so aus: > > # get patch > wget -O - https://github.com/gentoo/gentoo/pull/NNNN.patch | git am > > Bei Bedarf vor dem | bearbeiten oder vor dem Commit: > > # edit the PR > git rebase -i HEAD~1 > > Wenn Du magst, kannst Du den Autor anpassen: > > # edit authorship > git commit --amend --author="Joe Smith <[email protected]>" > > =========== > Wenn der Code absolut nicht verwendbar ist, die Idee aber gut war, kann > man auch selbst einen Commit daraus bauen und im Kommentar einfügen: > Suggested-by: Full Name <[email protected]> > > Methode von kernel.org > > Beste Grüße, > -- Johannes Hubertz Geschäftsführender Gesellschafter der hubertz-it-consulting GmbH Sitz: Grengeler Mauspfad 111a, D-51147 Köln, European Common, Handelsregister: Köln HRB55865, Ust.-ID Nr.: DE814465092 Tel.: +49 (0) 1607421564 Electronic Mail: [email protected] GnuPG Fingerprint: a81f e2da f1f9 a0e3 be20 b2b0 005e a2e3 cff5 a06f Ihr Service für Datenschutz und Informationssicherheit: Verlässliche Netzwerke für vertrauliche Kommunikation
