Компания GitLab, развивающая одноимённую платформу для организации совместной работы с Git-репозиториями, сообщила (https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l.../) об отказе от необходимости заключения специального CLA-соглашения (Contributor License Agreement) при передаче изменений, улучшений или исправлений проекту. Для участия в разработке теперь не нужно подписывать документ о передаче имущественных прав на использование своего кода в составе GitLab, а достаточно согласиться с условиями Developer Certificate of Origin (https://developercertificate.org/) (DCO).Документ Developer Certificate of Origin подготовлен юристами организации Linux Foundation и уже 13 лет используется (https://lkml.org/lkml/2004/5/23/10) при передаче изменений в состав ядра Linux, позволяя отслеживать авторство каждого изменения в коде. Принятие изложенных в документе условий осуществляется через указание при передаче патча строки "Signed-off-by: имя и email разработчика", что позволяет максимально упростить процесс привязки кода к авторам. Прикрепляя данную подпись к патчу, разработчик подтверждает своё авторство над передаваемым кодом и соглашается с его распространением в составе проекта или как часть кода под свободной лицензией.
В качестве причины перехода GitLab c CLA на DCO называется пожелания проектов Debian (https://wiki.debian.org/Alioth) и GNOME (https://www.opennet.dev/opennews/art.shtml?num=46558), которые планируют перевести свои инфраструктуры разработки на платформу GitLab. Отказ от необходимости подписания CLA-соглашения позволит разработчикам Debian и GNOME присоединиться к работе над GitLab и продвигать свои улучшения, реализованные для удовлетворения возникающих потребностей. Ожидается, что переход Debian и GNOME на GitLab позволит увеличить эффективность разработки и привлечёт новых участников в проект. Многие новые разработчики привыкли к GitHub и отдают предпочтение данной платформе, но использование GitHub в GNOME и Debian недопустимо в силу её проприетарного характера, в то время как платформа GitLab достаточно близка по возможностям и является свободным ПО.URL: https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=47495
Хорошая новость. Лично я не шлю патчи тем, кто требует что-то там подписать.
А я вообще никому патчи не шлю. ))
Присылайте патчи.
а я ни пачти, ни патчи
С этой бюрократией люди порой начинают производить идиократию. Вот коммит из QEMU:# git log CODING_STYLE
commit 56bef8511a576deef32d3e763b993b5001015c2d
Author: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Date: Fri Sep 30 02:04:28 2016 +0200CODING_STYLE: Fix a typo ("have" vs. "has")
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>И вы не поверите, что это за серьёзный патч, котоый имеет аж ДВЕ подписи и ЦЕЛЫЙ РЕВЬЮ:
diff --git a/CODING_STYLE b/CODING_STYLE
index e7fde15..f53180b 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -9,7 +9,7 @@ patches before submitting.
Of course, the most important aspect in any coding style is whitespace.
Crusty old coders who have trouble spotting the glasses on their noses
can tell the difference between a tab and eight spaces from a distance
-of approximately fifteen parsecs. Many a flamewar have been fought and
+of approximately fifteen parsecs. Many a flamewar has been fought and
lost on this issue.
QEMU indents are four spaces. Tabs are never used, except in Makefiles
Ты что, ведь там еще целый огромный хеш 56bef8511a576deef32d3e763b993b5001015c2d и время с точностью до секунды и часового пояса! Как страшно жить, не зная слово автоматизация.> ЦЕЛЫЙ РЕВЬЮ
т.е., по-вашему, ревью патча, изменяющего пару символов, не нужен?
> не зная слово автоматизация.автоматизация не имеет ни малейшего отношения ни к ревью, ни к sign-off, обе операции делают люди, и они именно для этого и придуманы, чтобы нельзя было автоматически пропихнуть что-то не то. А вот когда то и другое требуется по малейшему чиху - очень вероятно, что "автоматизация" вида "отъ..сь, вот вам подпись" приведет к подписыванию неглядя уже и опасных изменений в коде.
> т.е., по-вашему, ревью патча, изменяющего пару символов, не нужен?
ревью и целых две подписи к патчу, исправляющему банальную опечатку в документации? Вы бредите. Разумеется, не нужен и вреден. Даже если туда слово х^й написать вместо исправления - мир вовсе не рухнет, в следующем патче исправишь...если вообще хоть кто-нибудь заметит.
Порядок - он в головах должен быть. Умный разраб понимает, что могут возникнуть неудобства при работе с пробелами/табами. Особенно когда их меняют.И если человек, присылающий патч не понимает этого, то он мyдак. И вообще лентяй. И козявка.
О чём вы? Речь про патч, который делает замену одного слова с "have" на "has" и при этом им потребовалось собрать целый коммитет...
> коммитетНадеюсь, чтобы исправить ошибку в этом слове, комитет не нужен.
Шлите патч на комментарий и не возникайте тут.
> О чём вы?это вам была прекрасная иллюстрация на тему "тысячи глаз", и, кстати, в применении к code review и подписыванию коммитов оно работает точно так же - то есть, никак. Люди не в состоянии читать буквы и соображать головой. Чем меньше ваша разработка зависит от их умения и желания это делать, тем, на самом деле, только лучше.
> автоматизация не имеет ни малейшего отношения ни к ревью, ни к sign-off, обе операции делают люди, и они именно для этого и придуманы, чтобы нельзя было автоматически пропихнуть что-то не то. А вот когда то и другое требуется по малейшему чиху - очень вероятно, что "автоматизация" вида "отъ..сь, вот вам подпись" приведет к подписыванию неглядя уже и опасных изменений в коде.Видимо разработчики Qemu предпочитают следовать одному заведённому порядку, а не писать длинные списки исключений, когда порядок можно изменить.
> Ты что, ведь там еще целый огромный хеш 56bef8511a576deef32d3e763b993b5001015c2d и время с точностью до секунды и часового пояса! Как страшно жить, не зная слово автоматизация.О чём вы? Люди целенаправлено лично вручную ставили свои подписи на изменение в одном предложении с "have" на "has".
> т.е., по-вашему, ревью патча, изменяющего пару символов, не нужен?
Ревью патча + две подписи на файл CODING_STYLE, где банально изменяется опечатка? Нет не нужен.
Или вы считаете, что если бы приняли такой патч, где банально исправляется "have" на "has" в текстовом документе (то есть это даже не код), без подписи, то человек бы подом отсудил себе миллионы и бедный QEMU бы загнулся?
Они исправили "Many a flamewar have been fought" на "Many a flamewar has been fought"?
Странные. Я бы исправил на "Many flamewars have been fought"
> Странные. Я бы исправил на "Many flamewars have been fought"пришли им реквест. Они будут страшно рады заняться его изучением, аппрувом и подписыванием, вместо работы.
Такое ощущение, что это ты один в этом проекте в три лица горбатишься, а они ерундой все занимаются. Это опенсорс, поэтому вместо критики пошёл бы черканул пару строк им в код самостоятельно."Как советовать, так все чатлане, как работать..." © Кин-дза-дза
> Хорошая новость. Лично я не шлю патчи тем, кто требует что-то там подписать.Ты оставил Столлмана вместе со всем FSF без поддержки. А мы думали, что они уж точно фонд добра.
Тут один чувак доказывал что ФСФ не требует передачи прав на код. Кто ошибается?
Если это FSF-проект (gcc, gnulib, emacs,..), то это обязательно:Before incorporating significant changes, make sure that the person who wrote the changes has signed copyright papers and that the Free Software Foundation has received and signed them. We may also need an employer’s disclaimer from the person’s employer, which confirms that the work was not part of the person’s job and the employer makes no claim on it. However, a copy of the person’s employment contract, showing that the employer can’t claim any rights to this work, is often sufficient.
Т.е. иногда нужно даже ещё и у работодателя получать разрешение. Что дополнительно тормозит развитие FSF-проектов. Но зато они смогут отстаивать свою лицензию в суде.
Единственная альтернатива для личного кода - это передать свой патч в общественное достояние (public domain).
Источник: https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters
Т.е. я был прав, и ФСФ не принимает код под лицензией, которую люто советует другим... Лицемеры, о чём я и говорил.
"в то время как платформа GitLab достаточно близка по возможностям" - если присмотреться, то даже опережает.
> присмотреться, то даже опережает.а "космические корабли бороздяд просторы большого театра"!
Открыл для себя gitlab и теперь не могу никак закрыть. Отличная штука. В том числе, используется отдельная инсталляция в компании. Конечно, комьюнити эдишн, ибо всем жалко денег.
А не боишься?
https://www.opennet.dev/opennews/art.shtml?num=38342
https://www.opennet.dev/opennews/art.shtml?num=45957Я бы этим ребятам ничего не доверил.
Уязвимость 2013 года, недоступность на пару дней за несколько лет - так то надёжнее гитхаба и битбакета выглядит. Это без учёта того что проект открыт и можно развернуть хостинг у себя.
После второго случая у них очень правильные бэкапы с неоднократным дублированием. Они делали разбор полётов, почему все бэкапы на момент факапа были сломаны, и позже описали то, как у них сделано теперь.
> После второго случая*После случая по второй ссылке
1. Эти ребята сделали правильные выводы.
2. Для суперперестраховки можно развернуть GitLab на контролируемом сервере, а не использовать gitlab.com
> можно развернуть GitLab на контролируемом сервере, а не использовать gitlab.comтак и сделано, конечно. Не понимаю ссзб хранящих бизнес-данные у дяди
Эээ, а как же Gitea?
Это та, которая сама на гитхабе хостится?
Для ниосилевших коньсоль?
> Для ниосилевших коньсоль?Консоль никуда не делась. А удобная работа с merge requests появилась
По ходу в одиночку работаешь.
)) одиночкам и гит не нужен, new folder, new folder1, new folder old))))
> )) одиночкам и гит не нужен, new folder, new folder1, new folder
> old))))Одиночкам кодревью не нужен, а контроль версий любому нормальному человеку нужен.
Отличная новость про Дебиан!
Да, Alioth безнадёжно устарел. Как, впрочем, и вообще нехилая часть дебиановской инфраструктуры.