Питер Хинченс про Optimistic Merging: Сначала люди, потом код. Соберите правильное сообщество, и оно напишет нужный код

[el777]

А почему хорошая идея «deprecated»? Не взлетела на практике?

[indocoder]

Там же чуть далее написано

Note: this RFC is superсeded by http://rfc.zeromq.org/spec:42/C4

[Turkmenistan]

Я вообще противник open source.

[SamDark]

Почему?

[leventov]

Очень спорно. "Развитие событий" 2 ОМ, 3 ПМ, 4 ПМ и 4 ОМ непонятно откуда взялось. На самом деле будет так:

2 ОМ: будут молча мерджиться патчи с багами. Качество проекта в лучшем случае будет стоять на месте, в худшем — быстро ухудшаться. У новых пользователей от забагованности проекта будут шевелиться волосы.

3 ПМ: ничем не отличается от 3 ОМ.

4 ПМ: "Получаем перепалку, в которой грубой силой аргументов выигрывает тролль, что пораждает реакцию «бей или беги». Сообщество пушит отвратительные патчи." Извините, я ничего не понял. С какого рожна выигрывает тролль-то?

4 ОМ: вообще какой-то бред написан.

[leventov]

На заметку переводчику: "OM: existing contributor immediately reverts the patch." переводится как "контрибьютор немедленно откатывает патч", а не "все существующие контрибьюторы немедленно возвращаются в проект".

"second contributor joins" переводится как "другой контрибьютор присоединяется", а не "второй тип контрибьюторов присоединяется". Смысловая разница большая.

[abondarev]

Не согласен.

При 2 ОМ врядли будут мерджить молча. Тут простое правило, что бессмысленный (или ухудшающий) патч, он и в африке бессмысленный. И все таки большинство людей тратят свое время, чтобы улучшить проект. Да, порой им не хватает знаний, опыта или чего то еще, чтобы сделать это хорошо. Поэтому таким нужно помочь, не молча смерждить, а помочь сделать это хорошо. При этом, естественно, придется потратить время.

На счет 3 пункта. Просто у Вас как раз ПМ, и Вы перевели разработчиков из второй категории в третью, в этом случае действительно нет разницы.

Про 4 ПМ согласен, непонятно почему троль выигрывает.

А про 4 ОМ основной посыл, если я правильно понял, во фразе, «Вредоносные патчи навсегда останутся в истории гита». То есть при таком подходе, даже если потом сделать нормально, то в историии все равно останется след.

На самом деле, для каждого проекта подход уникален, более того, на разных стадиях развития проекта он должен меняться и исходить из конкретных условий и текущих целей.

[leventov]

2 ОМ это про таких людей, которые делают нужные вещи в принципе, с полетом мысли, честно прикладывают усилия, но редко когда напишут 5 строчек с первого раза без багов. Из-за невнимательности, наверное. ОМ по определению подразумевает, что мы сначала мержим эти баги, а потом правим пост-фактум, когда или падает CI (тут совсем не факт, что она упадет, потому что тесты покрывают не все), или кто-то ревьюит. Но когда что-то уже смержено и не упало в CI, очень велик соблазн забить на ревью или посмотреть в полглаза, потому что у всех контрибьюторов катастрофически не хватает времени ни на что. Таким образом баги и проникают в проект. Когда есть жесткое правило о двух пре-коммит ревью, вероятность проникновения багов в код уменьшается.

[abondarev]

Согласен, что при правиле о двух пре-коммит ревью вероятность уменьшается. Но именно, что вероятность, потому что никакое ревью, даже самое честное и тщательное, не сделает вероятность равной нулю. И тут, как говорится, все хорошо в меру! Если для того чтобы внести патч который явно исправляет какую то очевидную багу (опечатку, например), требуется ждать месяц, ведь Вы сами написали, что контрибъютеры заняты и хорошо проревьюить код не всегда получается оперативно, то это может угнетать. С другой стороны, конечно, если исходить из того что мерджится вообще без ревью, то это тоже бред. Как же тогда отделить 2 тип от третьего? В моем понимании, 2 типу, нужно помочь, а мерджить без ревью, это не помощь, а вредительство.