История изменений

В [2] видно, что автор - главный программер проекта

Так, может, Тс'о сам такой же патч написал? Там ведь не такое уж исправление, что два человека не могли его независимо друг от друга придумать.

Но! Этот патч исправляет очень острую проблему, которую нельзя вот так теперь оставить. С другой стороны, вы являетесь автором, и никто не имеет права взять ваш кусочек кода и сказать, что это «тривиальный» фикс (хотя его обнаружить было далеко не тривиально), и мы имеем право и так его закомитить.

Это, действительно, проблема. В некоторых местах её решают требованием подписать соглашение до того, как начнёшь отправлять патчи, — мейнтейнер нарочно не читает патчи от неподписавших. В других местах находят кого-нибудь, кто не читал этот патч, говорят ему, что надо сделать, и он сам пишет код (получается clean room). В третьих не парятся. Что же до обнаружения уязвимости, то ведь знание о наличии уязвимости не является объектом авторского права.

Вариант второй: создаётся ветка, ваш патч комитится, а потом второй патч облагораживает его, ветку «атомарно» сливают куда надо (т.е. ваш «сырой» патч ничего не может испортить).

Так в итоге-то в истории проекта что? Два разных коммита или один? Если два разных, то кто-нибудь может откатиться на твою оригинальную версию, а она работать не будет. Это препятствует обнаружению багов бинарным поиском и в проектах, где принята «прямая и ясная история изменений», не поощряется.

В конечном счёте, если ты не основной разработчик, мало кто тебя будет знать, пока ты сам не расскажешь, например, в резюме. Да и потом, если ты пишешь патчи так, что после тебя их приходится переделывать, это не очень хорошая рекомендация.

В [2] видно, что автор - главный программер проекта

Так, может, Тс'о сам такой же патч написал? Там ведь не такое уж исправление, что два человека не могли его независимо друг от друга придумать.

Но! Этот патч исправляет очень острую проблему, которую нельзя вот так теперь оставить. С другой стороны, вы являетесь автором, и никто не имеет права взять ваш кусочек кода и сказать, что это «тривиальный» фикс (хотя его обнаружить было далеко не тривиально), и мы имеем право и так его закомитить.

Это, действительно, проблема. В некоторых местах её решают требованием подписать соглашение до того, как начнёшь отправлять патчи, — мейнтейнер нарочно не читает патчи от неподписавших. В других местах находят кого-нибудь, кто не читал этот патч, говорят ему, что надо сделать, и он сам пишет код (получается clean room). В третьих не парятся. Что же до обнаружения уязвимости, то ведь знание о наличии уязвимости не является объектом авторского права.

Вариант второй: создаётся ветка, ваш патч комитится, а потом второй патч облагораживает его, ветку «атомарно» сливают куда надо (т.е. ваш «сырой» патч ничего не может испортить).

Так в итоге-то в истории проекта что? Два разных коммита или один? Если два разных, то кто-нибудь может откатиться на твою оригинальную версию, а она работать не будет. Это препятствует обнаружению багов бинарным поиском и в проектах, где принята «прямая и ясная история изменений», не поощряется.

В конечном счёте если ты не основной разработчик, мало кто тебя будет знать, пока ты сам не расскажешь, например, в резюме. Да и потом, если ты пишешь патчи так, что после тебя их приходится переделывать, это не очень хорошая рекомендация.

В [2] видно, что автор - главный программер проекта

Так, может, Тс'о сам такой же патч написал? Там ведь не такое уж исправление, что два человека не могли его независимо друг от друга придумать.

Но! Этот патч исправляет очень острую проблему, которую нельзя вот так теперь оставить. С другой стороны, вы являетесь автором, и никто не имеет права взять ваш кусочек кода и сказать, что это «тривиальный» фикс (хотя его обнаружить было далеко не тривиально), и мы имеем право и так его закомитить.

Это, действительно, проблема. В некоторых местах её решают требованием подписать соглашение до того, как начнёшь отправлять патчи, — мейнтейнер нарочно не читает патчи от неподписавших. В других местах находят кого-нибудь, кто не читал этот патч, говорят ему, что надо сделать, и он сам пишет код (получается clean room). В третьих не парятся. Что же до обнаружения уязвимости, то ведь знание о наличии уязвимости не является объектом авторского права.

Вариант второй: создаётся ветка, ваш патч комитится, а потом второй патч облагораживает его, ветку «атомарно» сливают куда надо (т.е. ваш «сырой» патч ничего не может испортить).

Так в итоге-то в истории проекта что? Два разных коммита или один? Если два разных, то кто-нибудь может откатиться на твою оригинальную версию, а она работать не будет. Это препятствует обнаружению багов бинарным поиском и в проектах, где принята «прямая и ясная история изменений» не поощряется.

В конечном счёте если ты не основной разработчик, мало кто тебя будет знать, пока ты сам не расскажешь, например, в резюме. Да и потом, если ты пишешь патчи так, что после тебя их приходится переделывать, это не очень хорошая рекомендация.