Разработка KDE

Я не разработчик чего либо, но не вижу проблемы в обмене дифами. Очень удобно по почте пересылать и вообще.

не вижу проблемы в обмене дифами

Если бы проблем не было, то и систем контроля версий тогда бы не существовало.

Очень удобно по почте пересылать и вообще.

Я бы ещё понял, если бы нужно было прислать git bundle.

Получать патчи от всяких сторонних один-раз-контибутеров удобнее почтой в виде диффа, да.

Зачем они тогда просят зарегистрироваться у них на сайте, тоже часть удобства? Как тогда работают не-один-раз-контрибутеры и зачем вообще делать какое-либо разделение?

И да, чем дифф-то удобней пул-реквеста в том же гитхабе? Или это как в анекдоте про армян и грузин?

И тут меня как окатило ледяным душем: они просят прислать diff-файл.

Наверняка они имели ввиду патч, который генерирует git по команде git format-patch HEAD~<число_коммитов>

Это ничем не отличается от собственно коммита.

И да, чем дифф-то удобней пул-реквеста в том же гитхабе?

Тебе же сказали, гитхаб только зеркало.

Зачем они тогда просят зарегистрироваться у них на сайте, тоже часть удобства?

Чтобы отфильтровать всякое говно?

Как тогда работают не-один-раз-контрибутеры и зачем вообще делать какое-либо разделение?

Через свой гит/что-там-у-них. А разделять, т.к. у них своих постоянных толпа огромная, удобство контроля. Ну и если там не гит (по историческим причинам), то ты обломаешься всё равно — это касается многих крупных проектов с давней историей.

Как тогда работают не-один-раз-контрибутеры

Пушат, вестимо.

зачем вообще делать какое-либо разделение?

Ну не давать же кому попало пушить, вот и разделение.

это как в анекдоте про армян и грузин

Расскажи.

Но вообще согласен, у KDE'шников наркоманская экосистема для разработчиков Phabricator и багтрекер тоже наркоманский.

Если бы перешли они на GitHub, возможно детские баги KDE были отловлены и пофикшены.

А так много репортов и PR'ов разбиваются от эту их регистрацию. В GitHub'е зашёл и создал Issue, прикрепил backtrace и дальше пошёл. В их местной багзилле я должен регистрироваться, продираться сквозь корявый поиск и прочую хрень. И баг этот будет висеть годами, потому что всем пофиг. А на GitHub'е сообщество могло бы подсобить.

- Армяне лучше, чем грузины.
- Чем?
- Чем грузины!

В GitHub'е зашёл и создал Issue, прикрепил backtrace и дальше пошёл

И кто будет разгребать тыщи и тыщи бестолковых issue выискивая там в тоннах ерунды крупицы золота?

KDE не настолько популярный проект (см. то же количество звёзд на их репозиториях), чтобы у него были тыщи и тыщи бестолковых issue.

Это хорошо, что у Dendy хватило терпения обернуть свой коммит в diff по их требованиям и переотправить. Но большинство тех кто сделает PR и получат отлуп — просто забьют.

Ну не давать же кому попало пушить, вот и разделение.

То-есть у них внутри команды у всех есть прямой доступ ко всему и отсутствует какой-либо access control? А снаружи только диффы на почту?

у Dendy хватило терпения обернуть свой коммит в diff по их требованиям и переотправить

Это и есть фильтр адекватности.

KDE не настолько популярный проект (см. то же количество звёзд на их репозиториях), чтобы у него были тыщи и тыщи бестолковых issue.

Так что ставить звездочки на зеркало (посмотрел их доку для вкатывания в разработку — там указан их собственный гит для получения исходников, т.е даже гитхаб не упоминается)? А перекатись туда — набегут.

тыщи и тыщи бестолковых issue

Во-первых, откуда взялись эти тыщи, причём бестолковых, фантазии? Таким образом весь гитхаб (гитлаб, битбакет, герриты... нужное подчеркнуть) можно отправлять на свалку — ишь, системы контроля версий захотели, окаянные! Только диффы на почту, только хардкор, только таким образом можно отфильтровать зёрна от плевел.

Во-вторых, тут главный вопрос в том, что KDE предлагают работать без системы контроля версий и без веток. Если я правильно их понял. Всё ещё жду комментариев от непосредственно вовлечённых.

фантазии

В «огороженных» багтрекерах и/или списках рассылки постоянно какая-то ерунда творится, что уж говорить о том, что начнется на популярной площадке.

ишь, системы контроля версий захотели, окаянные

У кде гит. Не публичный на сторонней площадке, а частично огороженный на собственной инфраструктуре.

Только диффы на почту, только хардкор, только таким образом можно отфильтровать зёрна от плевел.

Твой патч должен попасть ответственному за это «что-ты-там-пачлил». В почте это просто разрулить. А вот смог бы ты найти на гитхабе/другом-любом-гите среди множества репозиториев/веток нужное тебе и быстро? Или бы пнул не глядя куда попало?

То-есть у них внутри команды у всех есть прямой доступ ко всему и отсутствует какой-либо access control?

Они, вроде бы, через Phabricator работают. Отправляешь клиентом (arcanist) коммиты на ревью, кто-то ревьит и оно отправляется в основную репу. Сам я эту хрень толком не юзал, но скорее всего дела обстоят примерно так.

У кде гит.

То что у них там гит это понятно, откуда и зеркало. Только снаружи вам не гит, а хер с маслом.

В почте это просто разрулить.

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

У товарищей из KDE, насколько я понимаю, веток нет вообще. Понять к какой ревизии был создан тот или иной дифф невозможно. Если это так, то истории изменений для них не существует, а гит используется как файлопомойка, я такое наблюдал неоднократно на разных проектах. Даже если патч был для ранней версии — она никогда не будет обновляться.

Как им отправить ветку с набором патчей, в которых реализована определённая фича, я также затрудняюсь ответить. Ещё бы можно было понять, если бы они просили git bundle, который на часть вопросов даёт ответ.

С их главной страницы:

It should not take long before you are happily using Phabricator.

happily

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

Это и есть фильтр адекватности.

Ага. Наверное из-за избытка «адекватности» KDE-разработчиков в Debian, Fedora, RHEL, CentOS, Ubuntu и SUSE SLE по умолчанию используется GNOME 3, а не KDE.

У GNOME 3, хоть свой привычный всем GitLab юзается, куда можно отправить Issue или PR, а не какой-то наркоманский Phabricator.

Нужно, чтобы за право предоставить PR нужно было платить. И сразу «мусора» не станет.

при попытке сделать pull-request в github, я был послан на... kde.org с извинениями, мол github только хостит зеркало

дропнул квест на этом моменте

Наверное из-за избытка «адекватности» KDE-разработчиков в Debian, Fedora, RHEL, CentOS, Ubuntu и SUSE SLE по умолчанию используется GNOME 3, а не KDE.

Наверно, «адекватность» разработчиков KDE ни причём, а у авторов дистрибутитвов были другие причины для выбора Gnome. В частности, почему в Ubuntu выбран Gnome вместо собственной разработки Unity, объяснил вожак фирмы Canonical. Для Debian Gnome подходит больше, чем KDE (в качестве основного варианта), потому что в KDE используется не вполне свободная библиотека Qt. Права на неё принадлежат частной лавочке, которая даёт двойную лицензию - свободнную или коммерческую - но в любой момент может передумать и поменять условия лицензирования. Почему Gnome в Fedora - мне просто пофигу, пусть её пользователи хоть прыщами покроются, почему в RHEL - тоже возможно фирме RedHat не нравится зависимость от чьих-то прав на Qt. Всё это не имеет отношения к качеству Gnome и KDE и адекватности их разработчиков.

Автор темы должен обратиться в организацию KDE: -добрый день! Я ваш новый лидер проекта. Делайте так, как я вам укажу.

Ладно, по КДЕ прошлись. Ядро тоже будете хаить?

шоб в LKML написать, регистрация не нужна

Неужели кого-то пугает регистрация? Говоря про ядро, я имел в виду не использование им хипстерских гитхабов и гитлабов и отправка патчей в виде diff.

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

Говоря про ядро, я имел в виду не использование им хипстерских гитхабов и гитлабов и отправка патчей в виде diff.

По поводу диффов вам уже Линус ответил лет 10 назад: https://www.youtube.com/watch?v=asePnpn2RZs&t=30s

По поводу диффов вам уже Линус ответил лет 10 назад

GitHub
Начало работы апрель 2008 года

Этот ответ давался в условиях отсутствия современных сервисов совместной разработки.

богомерзкий фабрикатор

Уже почитал откуда ноги растут: фейсбук выплюнул домашнюю поделку на PHP, остальные не долго думая растаскали по сусекам. У меня на предыдущем проекте уже пытались другую поделку от фейсбука притянуть — React Native. И ты хоть в лепёшку разбейся, рассказывая про несовпадение области применения с целями проекта, главным аргументом с той стороны было: «ну это же фейсбук! ко-ко-ко...».

Вспоминаю слова Линуса с той самой презентации в гугле про тупиковую в зародыше идею сделать «правильный CVS» и назвать это SVN. Нельзя сделать правильную реализацию из defected-by-design концепта. То же можно сказать и про систему совместной разработки на основе обмена диффами.

Я ещё могу понять, когда на безрыбье и рак рыба. Но при наличии на рынке геррита, наверное лучшей системы управления кодом, это сколько нужно было принять веществ, чтобы опуститься до фабрикатора.

Сейчас придет альфа и пояснит что это называется «CI» и куча проектов с герритом живёт и благоухает :)

Они просили именно дифф или патч а формате гит их тоже устраивал? Что плохого в том, чтобы переслать патч? Он содержит все необходимые описания.

Я так отправлял кучкой комитетов в дерево генту, когда зеркало на гитхабе повредили злоумышленники стыревшие чей-то аккаунт.

Присланный diff проще наложить на созданную ветку. Или ты хотел, чтобы разработчик из твоего коммита выковыривал изменения? В гитхабе это достаточно просто делается на странице реквеста, но если их инфраструктура закрыта для остальных, то уже сложнее.

Они просили именно дифф или патч а формате гит их тоже устраивал?

А есть принципиальная разница?

Что плохого в том, чтобы переслать патч? Он содержит все необходимые описания.

В том-то и дело, что НЕ содержит. Ревизия в гите иммутабельна и определяет собой полное содержимое репозитория. Дифф это просто разница, непонятно к чему её применять.

Дядя Федя на том конце интернета будет чесать репу и чертыхаясь пытаться черрипикать этот дифф куда-попало, пытаясь угадать почему он не накладываясь. Или накладывается, но работает не так, как задумывал автор. Чтобы потом оказалось, что в оригинале перед этим патчем была ещё пачка других, что можно выяснить только в словесной перепалке.

Вот смотрю я на патч на фабрикаторе, который нужно отревьювить, а ревизии к нему не существует. Будь добр не промахнись с веткой, в которую будешь этот патч вытягивать, иначе рискуешь напроверять совершенно не то.

В прошлом когда у нас возникали подобные вопросы, то просто сверяли SHA1 коммитов, чтобы убедиться, что ссылаемся на ту же ревизию. С герритом/гитхабом и прочими такой вопрос даже не стоит. А с фабрикатором это просто невозможно. Хвалёная иммутабельность гит-коммитов идёт по первичному женскому признаку.

Присланный diff проще наложить на созданную ветку.

Если он накладывается. А если нет, то что? И даже если накладывается, проект может не собираться. Или собираться, но не работать. Ревизия имеет значение.

Есть- просто diffне содержит никакой информации о коммите и о предложившем его.

Дифф понятно к чему применять, если с тех пор сильных отличий в дереве не было. Поэтому и уточняю, что именно они попросили diff или git formated patch.

> KDE

Если бы перешли они на GitHub

[fatmode=on]

микрософт не потянет еще один windows у себя в гите :)

Вспоминаю слова Линуса с той самой презентации в гугле про тупиковую в зародыше идею сделать «правильный CVS» и назвать это SVN. Нельзя сделать правильную реализацию из defected-by-design концепта. То же можно сказать и про систему совместной разработки на основе обмена диффами.

Странно, что в одном обзаце взаимоисключающие параграфы. То-то Линус топит за патчи в почтовой рассылке.

На самом деле понятно почему - иначе получится монстр на 100 терабайт, так же, когда МС загнала винду в гит, и пришлось писать драйвер для поддержки супербольших репов для винды.

Про фабрикатор/аркаинст уже несколько раз написали. Отправлять на ревью можно не только диффы, но и коммиты.

Привязка изменений к конкретному коммиту это бред. Если это новая фича, она должная накладываться и работать относительно последнего коммита мастера. Если это багфикс, то относительно стабильной ветки, с возможность потом замерджить в мастер.

Какая разница, если ты писал патч относительно коммита, который был сделан 20 лет назад? Есть текущее состояние ветки и когда патч будет приниматься, он будет накладываться именно на это состояние.

Единственная проблема фабрикатора это ущербный и слишком сложный интерфейс арканиста.

Привязка изменений к конкретному коммиту это бред.

И вуаля... в итоге пропадает атомарность и возможность той же отладки путём какого-нибудь git bisect, а на выходе получается, на выходе получается... http://esxi.z-lab.me:666/~exl_lab/screens/plasmacrash8.png

После того как такое измнение принято, репа ничем не отличается от реп любого другого проекта. Так что это не мешает отладке потом.

А если при принятии изменения его сложно ревьюить из-за того что нет контекста, значит проблема намного более глубоко :^)

Алсо, почему с таким подходом вспоминают именно плазму, а не любой другой проект KDE? Потому что это не связано с подходом. Если она и падает, то из-за кривых QML и дров для видяхи. Про это ещё Мартин писал.

Привязка изменений к конкретному коммиту это бред.

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

Так называемая «привязка» это способ указать в какой ревизии этот патч разработался у автора, чтобы от этой информации двигаться дальше. К примеру, если это исправление бага, то патчи можно ребейзнуть на ревизию ниже, чтобы можно было смержить в соответствующие ветки, где этот баг присутствует.

В том же геррите в порядке вещей, когда разработчик предоставляет коммит и мерж-коммит в целевую ветку, и они ревьювятся по-отдельности.

Ещё раз, никакой «привязки» нет, указание ревизии необходимо для понимания в какой среде коммит работает у автора. А не носиться с диффами и недоумевать, почему этот самый дифф работает у всех по-разному, а у кого-то вообще не накладывается.

BrightScript. Сколько же этих языков понапридумывали.

И тут меня как окатило ледяным душем: они просят прислать diff-файл. Протёр глаза, ущипнулся, сверился с календарём — 2018-й подходит к концу, перевёл глаза обратно в монитор.

В ядре вообще всё через рассылку делается.

сделал им diff, выковырял из коммита описание

git format-patch -U9999

Про -U9999 у них не сказано, но это облегчает ревью. Лишние строки фабрикатор скрывает, но их потом можно открыть, как на Github. Хотя в твоём случае файлы только добавляются, поэтому контекст не нужен.

и отправил патч, завершив свою часть квеста.

Нет, квест ещё не закончился. Нужно проследить, чтобы кто-нибудь влил твои патчи. Сами по себе они не вольются. Разработчики могут забыть, что ты — человек со стороны, и у тебя нет прав коммитить в репозитории. Если за неделю после принятия не вливают, надо напомнить кому-нибудь из ревьюверов.

2018-й подходит к концу

Кстати, давно Github научился открывать комментарии из ревью разом? Раньше с сразу публикуемыми комментами было неудобно ревьювить.

Разработка KDE

Так оно же deprecated теперь.

Нет, квест ещё не закончился. Нужно проследить, чтобы кто-нибудь влил твои патчи.

У слову сказать, там мейнтейнер откликнулся в течении часа, выразил своё фе, я поправил, он заапрувил. Теперь слежу когда оно вольётся в ветку.

потому что в KDE используется не вполне свободная библиотека Qt

Шо! Опять?

Права на неё принадлежат частной лавочке, которая даёт двойную лицензию - свободнную или коммерческую - но в любой момент может передумать и поменять условия лицензирования.

Точно то же самое может произойти с любым проектом под свободной лицензией. И точно такой же будет реакция — форкается последняя свободная версия и развивается дальше, вероятно, под другим именем. Истории успеха: MySQL -> MariaDB, OpenOffice -> LibreOffice и возможно, xorg-server (хотя есть мнение, что в последнем случае шум был раздут зря).

Qt, если уж на то пошло, выпускается под тройной лицензией: GPL, LGPL, коммерческая (под LGPL доступны не все модули). И безвозвратно огородить можно, как ты понимаешь, только последнюю.

По теме: не разработчик KDE, но не вижу ничего страшного в посылке diff-файлов.

Распечатай им свой патч на бумаге и отправь почтой, в конверте.

Я бы ещё понял, если бы нужно было прислать git bundle.

man git-send-email

К тому же КДЕ исконно использовал SVN, а не хипстерский тулкит.