Dlaczego niektóre projekty open source nie akceptują żądań ściągania, a jedynie przesyłanie plików łatek pocztą e-mail

16

Dlaczego niektóre projekty Open Source nie akceptują żądań ściągania, ale wymagają od autorów tylko łatania plików e-mail? np. Git Chociaż publikują kod w github lub innym hostowanym serwerze SCM. Wysyłanie plików łatek nie jest interaktywne ani wygodne. Plik łatki jest staromodny. Żądania ściągania są interaktywne. Inne osoby mogą również dyskutować.

linquize
źródło
1
Patrząc na to, co to jest „żądanie ściągnięcia” (nigdy nie używano git i nie jest wspólne dla wszystkich SCM), wydaje się, że mówisz: „Hej, mam tu zmianę!” Inni mogą następnie pobrać od ciebie, jeśli chcą, i przejrzeć. Czy to działa, jeśli przejdziesz do trybu offline? Jeśli nie, byłby to świetny powód, aby preferować wiadomości e-mail z poprawkami.
Edward Strange
1
@CrazyEddie: github wysyła (lub może wysłać) wiadomość e-mail do opiekunów projektu po przesłaniu żądania ściągnięcia. Ten e-mail zawiera opis żądania ściągnięcia oraz listę zatwierdzeń i zmienionych plików. Oczywiście musisz być online, aby otrzymać ten e-mail i pobrać zatwierdzenia, ale dotyczy to również e-maili z poprawkami.
John Bartłomiej
Pliki łatek są powszechnie obsługiwane. Żądania ściągania są specyficzne dla dostawcy. Dlaczego miałbyś oczekiwać, że opiekunowie je zaakceptują?
Anonimowy

Odpowiedzi:

17

Może to zależeć od tego, kto będzie odpowiedzialny za przyjęcie twojego żądania ściągnięcia.

Jeśli to Linus Torvalds , cóż ... lepszy jest dobry stary patch :

Nie wykonuję żądań ściągania na githubie.

github wyrzuca wszystkie istotne informacje, takie jak posiadanie nawet ważnego adresu e-mail dla osoby, która prosi mnie o pobranie .
Diffstat jest również niedobór i bezużyteczny.

Git jest wyposażony w ładny moduł generujący żądanie ściągnięcia, ale zamiast tego github postanowił zastąpić go własną, całkowicie gorszą wersją.
W rezultacie uważam github za bezużyteczny do tego rodzaju rzeczy.

Nadaje się do hostingu , ale żądania ściągania i edycja zatwierdzeń online są po prostu śmieciami.
Powiedziałem ludziom z Github o moich obawach, nie myśleli, że mają znaczenie, więc się poddałem. Zgłoś błąd w github.

Szczegóły:

Aby mnie wyciągnąć z github, trzeba:

  • (a) złożyć prawdziwe żądanie ściągnięcia, a nie badziewne bzdury, które robi github, gdy poprosi się go o pociągnięcie:
    • prawdziwe wyjaśnienie ,
    • prawidłowe adresy e-mail ,
    • właściwy dziennik , oraz
    • właściwy diffstat .
  • (b) ponieważ tożsamość github jest losowa, oczekuję, że żądanie ściągnięcia będzie oznaczonym tagiem , dzięki czemu będę mógł zweryfikować tożsamość danej osoby.

Odmawiam również pobierania zatwierdzeń dokonanych za pomocą interfejsu sieciowego github.
Ponownie dlatego, że sposób, w jaki działa interfejs sieciowy github, te zatwierdzenia są niezmiennie bzdurą.
Zatwierdzenia wykonane w github niezmiennie mają całkowicie nieczytelne opisy, ponieważ funkcja dokonywania zatwierdzeń github nie robi żadnej z najprostszych rzeczy, których ludzie jądra oczekują od wiadomości zatwierdzenia:

  • brak „krótkiego opisu jednowierszowego w pierwszym wierszu”
  • bez zdrowego zawijania długiego opisu, który wpisujesz: wiadomości github commit są zwykle (jeśli w ogóle mają jakiś opis) jedną długą nieczytelną linią.
  • brak wylogowań itp., które są wymagane do przesyłania jądra.

github może ułatwić pisanie dobrych komunikatów zatwierdzania i wymuszać odpowiedni „oneliner dla krótkich dzienników i gitkpełne wyjaśnienie pełnych dzienników”.
Ale github nie.
Zamiast tego interfejs „zatwierdzania w sieci” github jest jednym okropnym polem do wprowadzania tekstu bez absolutnie żadnego zdrowego sposobu na napisanie dobrze wyglądającej wiadomości.

Gdy pojawi się pytanie w polu tekstowym dla komunikatów zatwierdzania:

@torvalds Interfejs użytkownika GitHub zatwierdzenia zapewnia pole tekstowe dla komunikatów zatwierdzania.
Obsługuje to nowe wiersze i ułatwia wykonywanie ładnie sformatowanych komunikatów zatwierdzania :)

Nie, nie ma.
Obsługuje pisanie długich linii, których * * * nie masz pojęcia, jak długie są.
Obszar tekstowy nie wykonuje podziałów linii i nie ma sposobu, aby ocenić, dokąd pójdą podziały linii.

Innymi słowy, bardzo utrudnia to wykonywanie „ładnie sformatowanych komunikatów zatwierdzania”.
Nie wymusza również trywialnego modelu „oneliner for shortlog”
, więc komunikaty zatwierdzania często wyglądają jak totalna bzdura w shortlogach i gitku.

Więc interfejs użytkownika zatwierdzania github powinien mieć

  • oddzielne okno tekstowe „shortlog” w jednym wierszu, aby ludzie nie mogli tego zepsuć.
  • jakiś sposób na rzeczywiste zawijanie wyrazów przy standardowym 72-kolumnowym znaku.
  • przypomnienia o podpisaniu umowy itp., których niektóre projekty potrzebują ze względów specyficznych dla projektu lub nawet z powodów prawnych.
VonC
źródło
5
lub krótka wersja; on / ona, która jest właścicielem projektu, może go uruchomić w dowolny sposób. Jeśli nalegają na wydrukowanie zmian pocztą ślimakową, to właśnie w ten sposób musisz ją przesłać (choćby tak opóźniona).
Ken Henderson
3
Jeśli zatwierdzenie nie spełnia wymagań właściciela projektu, może on wybrać, a następnie zmienić zatwierdzenie zgodnie z tym, czego chce. Ważne jest, aby cenić wszelkie wkłady wniesione przez innych programistów. Szkoda, że ​​właściciel projektu po prostu odrzuca składki tylko z powodu niespełnienia formatu zatwierdzenia.
linquize
1
@linquize Projekty open source zwykle nie mają siły ludzkiej. Można by zaoszczędzić czas „wybierania i poprawiania”.
słaby
1
„pisanie długich linii, których * nie wiesz, * jak długo one są.” Cóż, wydaje się to już rozwiązane, teraz ostrzega cię dość długo o zbyt długiej pierwszej linii i ma dwa oddzielne pola tekstowe na krótką i szczegółową wiadomość.
heltonbiker
1
Linus narzeka na implementację github, ale to nie znaczy, że żądania ściągania są ogólnie złe. W rzeczywistości jest ponownie uruchamiany, aby wysyłać pliki łatek pocztowych zamiast korzystać z ładnego interaktywnego interfejsu internetowego, który działa bezpośrednio z git zamiast importować / eksportować pliki
Mike76