Модифікація програми з відкритим кодом

Що таке загальний робочий процес, коли я хочу додати функцію до програми з відкритим кодом, яку я спочатку не писав? Як дізнатися код? Як знайти місце, яке потрібно змінити чи додати? Як насправді зробити зміни, не порушуючи нічого іншого? Як перевірити, що все ще працює?
Які загальні вказівки щодо такого проекту?

open-source

— Дани
джерело

Ви також повинні подати свої зміни до проекту, як правило, як виправлення, щоб інші могли отримати користь.

Є якийсь протокол, всі більш-менш сприймають його з часом, але ось він, розкручений.

Ви завантажуєте розподілене джерело.
Ви трохи починаєте навігацію коду
- Якщо це скомпільована програма, ви дізнаєтеся прямо зараз , як скомпілювати його.
- Якщо ви не зможете його скласти, ви повідомляєте автору / списку розсилки та запитуєте вказівки
Якщо ви дійсно нічого не розумієте в коді ...
- Ну, ні, ви їх не запитуєте.
- Ви кидаєте це, оскільки ви, мабуть, не дорівнюєте і не можете бути реальною допомогою.
- Ви надаєте функцію, якщо автор (и) приймає запити щодо функцій.
Інше
- Ви знаходите місце, яке хочете змінити.
- Якщо вам цікаво якась незначна деталь, ви запитаєте автора / списку розсилки та поясніть свої наміри.
- Ви переходите до основного каталогу дистрибутива (верхній, який виходить із розпакування / розпакування)
- ви diff -ur . > mypatch.path
- Ви надсилаєте mypatch.patchавторові пояснення, що ви зробили, чому ви це зробили, і (як ви вже є) ви чітко заявляєте, що відмовляєтесь від прав на патч на них.
якщо автор (і) не любить ваш внесок
- ви перевіряєте, чи є спосіб випустити свою модифікацію як якийсь плагін
  - у такому випадку тепер ви збираєтесь стати плагіном .
- ще
  - ви розгадуєте про свою ситуацію в своєму блозі і випускаєте там патч, можете безкоштовно завантажити та спробувати своє пояснення та свої зусилля,
  - Ви переслідуєте раз у раз систему помилок / список розсилки, намагаючись придбати підтримку свого патча. Уникайте заборони.
- ні в одному з цих випадків ви не розшифровуєте код , оскільки це дуже втомлюючий і невдячний процес, навряд чи ви зможете йти в ногу з часом: це залишить користувачів сумними і розгубленими. Forks повинен справді траплятися лише тоді, коли велика корпорація намагається знущатись над своїми рішеннями на частину OSS .
ще
- Ви отримуєте подальші вказівки від цього автора

Зі сторони: є нещодавня альтернатива diff -ur .патчу і це спосіб github .

Ви "роздвоюєте" їх код на github під своїм ім'ям
(тепер у вас є копія їх коду у вашому обліковому записі)
підключіть свій git до вашої особистої копії,
внесіть свої зміни на це, завітайте до них,
і скажіть головному авторові (авторам) переглянути ваш проект github.
Якщо їм це подобається, вони синхронізуються .
В іншому випадку ви можете пов’язати свій "gitfork" у своєму блозі.

— ZJR
джерело

Все добре, поки ви не запропонуєте авторам ОП розгоряти автори продукту за те, що вони не сприймають новий патч функцій, незрозуміло, чи це мало бути смішним чи серйозним, у будь-якому випадку, ДУЖЕ погана форма ефективно плакати, як маленька дитина, на весь світ, тому що команді продуктів не подобається / хочете, щоб ваш новий патч функцій. В будь-якому разі розміщуйте це, але завжди будьте великодушними, якщо його не прийняли, незалежно від того, наскільки це рішення нелогічне. -1 - FYI, я з радістю відмінюю свій голос, якщо ви його знімете.

— окудо

Додаток, який я хочу змінити, дотримується суворого стандарту, який зі своїми змінами порушить стандарт. Я думаю, що навіть не в змозі попросити застосувати свій пластир.

— Дані

@Slomojo OSS повна незрілих людей, і подібне відбувається постійно, кожен повинен бути готовий працювати як мул, а потім бути відхиленим на основі того, що іноді є твердим, а іноді і суперечливим . І тоді, принаймні, ти завжди маєш шанс зайнятися цим і знайти людей, які вважають, що ти, можливо, маєш рацію. Тепер, не зважаючи на розхитування , це був би неправильний і дуже химерний крок.

— ZJR

@Dani lol, вам дійсно доведеться взяти патч і поділитися з цим способом. Уникайте роздрібнення, оскільки це затребує ваше життя, ви відчуваєте, як реконструювати безперервно без перерви. ... у будь-якому випадку, перевірте, чи немає у списку розсилки та системи звітів про помилки, чи є хтось зацікавлений у такому розширенні, можливо, ви не один. Aaaand найкраще було б, щоб у них був якийсь API, який потрібно розширити, або що-небудь з додатком, щоб підключити ваші зміни. Це завжди найкращий варіант у таких випадках: управління плагіном . ... відредагує це.

— ZJR

якщо є автоматизовані тестові випадки, запустіть їх перед тим, як подати виправлення.

— Ононе

Зазвичай.

Якби це був випадковий проект ОС, ви, швидше за все, виправляли б тут незначні помилки.

Врешті-решт, ви подасте купу змін як "виправлення".

Зазвичай ви отримаєте права на виконання зобов’язань, якщо ваші речі хороші.

Я розмовляю загалом і настільки ж неясні та неспецифічні, що пояснюються питанням

— MattyD
джерело