Разработчики языка программирования Python приняли решение (https://mail.python.org/pipermail/core-workflow/2016-January...) (PEP-481 (https://www.python.org/dev/peps/pep-0481/)) заменить Mercurial (https://hg.python.org/) на Git и перейти на использование GitHub (https://github.com/python) в качестве основной площадки для разработки. Изменения коснуться только репозиториев с кодом и системы рецензирования. Отслеживание ошибок и Wiki останутся без изменений.
В процессе обсуждения возможных путей оптимизации процесса разработки также рассматривалась (https://www.python.org/dev/peps/pep-0507/) платформа GitLab, но, в конечном счёте, выбор был сделан в пользу GitHub, так как данная платформа более привычна для основных разработчиков и сторонних участников. Предпочтение GitHub также отдали Гвидо ван Россум (Guido van Rossum), великодушный пожизненный диктатор проекта Python, и несколько ключевых разработчиков проекта.
Кроме того, несколько отстранившихся от участия в проекте разработчиков выразили желание вернуться к активной разработке в случае перехода на Git и GitHub. Для новичков Git также отмечен как предпочтительный вариант, так как многие не решались подключиться к разработке из-за применения собственной платформы рецензирования и системы контроля версий Mercurial. Напомним, что до 2009 года для разработки Python использовался Subversion, после чего был осуществлён переход (https://www.opennet.me/opennews/art.shtml?num=21004) на Mercurial (по популярности в то время Mercurial был примерно на одном уровне с Git, но основным фактором выбора стало то, что данная система написана на Python).
URL: https://mail.python.org/pipermail/core-workflow/2016-January...
Новость: http://www.opennet.me/opennews/art.shtml?num=43619
Методически складываем все яйцы в одну корзину ..
Git же распределённая система. Думаю, что если регулярно делаются бэкапы, то даже в самом плохом случае (уничтожение всего github) ничего страшного не произойдёт.
Master уж точно есть в виде локальной копии у каждого из активных разработчиков.
Один хостинг.Один раз взломают и все скомпроментированы ..
как раз в этом случае проще выявить проблемы - все на виду и прозрачно
В git у каждого разработчика локально храниться копия базы, распределенность выше некуда
>В git у каждого разработчика локально храниться копия базы, распределенность выше некудаФайлы? Трекер? Пулреквесты? Фанбои такие фанбои.
Можно подумать, что сейчас трекер распределённый. А пулл-реквесты, разумеется,у их авторов на машинах лежат. Впрочем, то, что три четверти FOSS на серверах одной конторы развиваются - стрёмно, конечно.
гы гы fossil forever ))
>>В git у каждого разработчика локально храниться копия базы, распределенность выше некуда
> Файлы? Трекер? Пулреквесты? Фанбои такие фанбои.Даже в случае мгновенного тотального выключения всея github'а (что можно приравнять к IT катастрофе), ничто не помешает поднять gitlab и склонировать репу туда. Потеряются ветки обсуждений, но это все равно очень простое решение проблемы в условиях катастрофы.
Мне не приходят в голову более разрушительные ситуации, которые могут создать значительные проблемы от использования github.
Может вы поделитесь идеями?
> Даже в случае мгновенного тотального выключения всея github'а (что можно приравнять к
> IT катастрофе)А если хранить код в разных местах, то падение одного сервиса не то что не будет IT катастрофой, но и вообще мало на ком отразится.
Сам факт монополии github уже вызывает опасение тем, что все монополисты склонны злоупотреблять своим положением.
>> Даже в случае мгновенного тотального выключения всея github'а (что можно приравнять к
>> IT катастрофе)
> А если хранить код в разных местах, то падение одного сервиса не
> то что не будет IT катастрофой, но и вообще мало на
> ком отразится.Git как раз и помогает хранить код в разных местах. У каждого разработчика на компьютере отдельная копия со всеми коммитами.
github накрылся и нужно пушить в другое место? git remote add и работаешь дальше.
> Git как раз и помогает хранить код в разных местах. У каждого
> разработчика на компьютере отдельная копия со всеми коммитами.Детка, это умеет делать любая DVCS. Например тот же Mercural.
> github накрылся и нужно пушить в другое место? git remote add и
> работаешь дальше.В реальности, "код" - наверно даже не половина дела. Есть много
разных вещей, помимо гита, которые не "пушатся" по взмаху волшебной
палочки (батрекер, например).
>> Git как раз и помогает хранить код в разных местах. У каждого
>> разработчика на компьютере отдельная копия со всеми коммитами.
> Детка, это умеет делать любая DVCS. Например тот же Mercural.Совершенно верно.
>> github накрылся и нужно пушить в другое место? git remote add и
>> работаешь дальше.
> В реальности, "код" - наверно даже не половина дела. Есть много
> разных вещей, помимо гита, которые не "пушатся" по взмаху волшебной
> палочки (батрекер, например).Вы посмотрите всю ветку, кому и на что я отвечал.
Человек заявил "там же все, а если накроется?"
Я ответил, что чтобы накрылось, нужна настоящая IT катастрофа.
Например мгновенное выключение всея гитхаба (что оооочень маловероятно).
Но даже в этом случае разработка мгновенно переедет на gitlab.
Да, багтрекер и обсждения потеряются, но это небольшие потери для такого серьёзного проишествия.Потом другой человек (наверное, незнакомый с понятнием DVCS) предложил "хранить код в разных местах".
Я ему ответил, что git это умеет из коробки.А теперь вы ответили "это умеет не только git" и "а как же остальные вещи, кроме кода".
И начался новый виток обсуждения по кругу.
> Но даже в этом случае разработка мгновенно переедет на gitlab.Так уж и мгновенно? Как пользователи найдут новый адрес проекта проект? Что будет с проектами с малым количеством пользователей и без активной разработки на данный момент?
> Да, багтрекер и обсждения потеряются, но это небольшие потери для такого серьёзного проишествия.
ИМХО это если не половина проекта, так треть уж точно - так как там находятся обсуждение и сведенья почти о всех ключевых решениях и причинах их принятия или отклонения и о возможных решениях в будущем.
> Потом другой человек (наверное, незнакомый с понятнием DVCS) предложил "хранить код в
> разных местах".
> Я ему ответил, что git это умеет из коробки.Вы меня не поняли - я говорил не о локальном хранении кода, а об удаленных сервисах, таких как github. До появления github, отключение одного сервиса мало что значило. По этому я и передерживаюсь той точки зрения, что использование различных сервисов/хостингов позволяет свести к минимуму проблемы (для СПО в целом) при отключении одного из них.
>>> Git как раз и помогает хранить код в разных местах. У каждого
>>> разработчика на компьютере отдельная копия со всеми коммитами.
>> Детка, это умеет делать любая DVCS. Например тот же Mercural.
> Совершенно верно.Ну и зачем тогда на git переходить? Потому что молодежно?!)
> Я ответил, что чтобы накрылось, нужна настоящая IT катастрофа.
Либо просто владельцы гитхаба захотят однажды поиметь больше бабла.
> Да, багтрекер и обсждения потеряются, но это небольшие потери для такого серьёзного
> проишествия.Поучаствуй вы хоть в одном нормальном проекте - такую чушь вы не пороли б.
Да, раз уш пошла такая пьянка (переход на Git) - Python сделал бы много
хорошего, выбрав GitLab. Технических приемуществ Gihub не имеет.Впрочем, вероятнее всего пересилит мнение толпы хомячков с GitHub.
Ты так говоришь, как будто толпа хомячков — это не фича :D
> Ты так говоришь, как будто толпа хомячков — это не фича :DЭто не фича, а сила. Причем больше деструктивная.
PS
В PEP приводят в пример научные приложения на Python (стек scipy.org). Так вот
на самом деле - там очень разное отношение к хомячкам с гитхаба. Есть проекты,
ориентированные на непременный "enjoyment" в процессе кодирования и доступность процесса
для самого тупого школия. Они постоянно участвуют в разных GSoC и вообще трепетно
относятся к числу контрибьютеров. С другой стороны, есть такие как IPython - где
никаких GSoC (разработчики прямым текстом пишут о том, что от этого индусского
школия один вред), всю работу делает небольшая группа.Данная выборка показывает, что второй подход - успешнее, если критерием
выступает получающийся код.
Питон как раз для хомячков, он теперича заместо бэйсика.
Глупости какие...
Гитхаб не монополист, есть битбакет, гитлаб плюс ещё мешок сервисов поменьше. Если гх начнёт выпендриваться, то, хвала рынку, быстро потеряет пользователей. Это же не Газпром, чья монополия ревностно охраняется государством.
> Гитхаб не монополист, есть битбакет, гитлаб плюс ещё мешок сервисов поменьше.Пока есть. Угадай с трех раз, что будет с гитлабами, если
хомячки продолжат выбирать себе хостинги по принципу "где
больше зарегистрировано потенциальных разработчиков".> Если гх начнёт выпендриваться, то, хвала рынку, быстро потеряет пользователей. Это же
> не Газпром, чья монополия ревностно охраняется государством.Ох, рыночная либезьяна с дерева слезла - поет оду рынку, аж слюни текут.
Монополии не надо охранять, дебил. Они сами себя прекрасно
охраняют. На самом деле - полностью все наоборот, это ваш замечательных
рынок с конкуренциями - надо охранять от монополий, иначе те
изгадят даже видимость благополучия. В "нормальной" капстране
так и происходит - государство выполняет функцию рыночного регулятора.
> В git у каждого разработчика локально храниться копия базы, распределенность выше некудаВы так говорите, что можно подумать, что в случае с Mercurial это не так.
Для этого надо знать что-то кроме модного слова GitHub.
GitLab или GitHub больная тема. Тоже долго выбирали и остановились на GitHub.
В GitLab лишь одно большое преимущество - возможность запустить Community Edition на своём сервере. В остальном GitLab проигрывает и приходится выбирать между открытостью платформы или функциональностью/привычностью/сочетаемостью с другими проектами. Git во многом гасит риски. На поддержание своей инфраструктуры GitLab нужно много ресурсов, в GitHub вся инфраструктура готова и неплохо справляется с разными DDoS. Минусы в том, что GitHub как коммерческую компанию могут купить/запретить/развалить/расколоть, а инфраструктура неподконтрольна для аудита, злоумышленники её могут незаметно взломать и получить доступ к аккаунтам разработчиков.
apt-get install gitlab-ce
Это пока проектом занимается полтора землекопа и нет DDoS. Да и работа в этом случае превращается в гонку админ первый наложит патч или злодей заметит уязвимость. С периодическими remote code execution дырами (https://about.gitlab.com/2015/11/25/gitlab-8-dot-2-1-securit...) при использовании GitLab рисков быть хакнутым на порядок больше, чем рисков GitHub из-за его vendor lock.
Ага, security by obscurity рулит.
> В остальном GitLab проигрываетСмешно, да. Основное преимущество Гитхаба -- популярность. Если смотреть исключительно на функциональность -- Гитлаб его уже как минимум догнал (последней фичей были pages, которые недавно добавили).
pages пока только в платной версии.зато человеческую интеграцию с другими ci-серверами они недавно совсем выпилили в угоду своему. не вендор-лок, говорите?
> интеграцию с другими ci-серверами они недавно совсем выпилилиМожно пруф?
> pages пока только в платной версии.Мы сравниваем с Гитхабом, где community-версии нет в принципе. Так что всё одинаково -- pages есть в онлайн-версии и в платной оффлайновой.
> зато человеческую интеграцию с другими ci-серверами они недавно совсем выпилили в угоду своему. не вендор-лок, говорите?
Ты врёшь, я так скажу. Почему-то в списке сервисов в проекте я вижу полторы страницы -- и Дрон, и Дженкинс, и Тимсити и прочее. Плюс вебхуки для всякой экзотики.
хм, у меня в ce jenkins отвалился при переходе на 8.х. старые хуки перестали работать, новые ввести невозможно -- нет возможности указать, что ci-сервер у тебя на другой машине.мы точно про gitlab community edition говорим? и там есть интеграция с jenkins? раньше (во времена 7.x) интеграция сводилась к тому, что jenkins прикидывался gitlab ci, а gitlab с ним общался, в 8.x это выпилили.
> Почему-то в списке сервисов в проекте я вижу полторы страницы -- и Дрон, и Дженкинс, и Тимсити и прочее.
drone и teamcity вижу, jenkins не вижу. gitlab ce 8.3.5.
> gitlab ce 8.3.5.8.3.2, конечно же.
пошёл возвращать машину времени.
> мы точно про gitlab community edition говорим? и там есть интеграция с jenkins?Лично я сравниваю онлайн-версии Гитхаба и Гитлаба. Ну естественно, что в CE что-то урезано.
я пробовал пользоваться онлайн-гитлабом. и свалил обратно на битбакет: у него с ui ощутимо получше, а в остальном то же самое.онлайн-гитхабом и гитлабом на собственном сервере до сих пор пользуюсь тоже. оттого и хорошо помню, чего в community-версии не хватает.
GitLab пока слишком глючный и безбожно дырявый, к сожалению. С безопасностью в GitLab всё очень плохо, с его манерой запуска shell-врапперов, неисправленных и невыявленных дыр там непаханное поле.Ещё хуже, что после провальных "remote execution" дыр 2013 года (http://www.cvedetails.com/vulnerability-list/vendor_id-13074...) они перешли к порочной практике тихого исправления дыр без присвоения CVE. Пример https://about.gitlab.com/2015/11/25/gitlab-8-dot-2-1-securit.../ remote code execution Nov 25, 2015. О многих дырах можно только догадываться, общий объём можно оценить по списку https://about.gitlab.com/vulnerability-acknowledgements/
Тем, кому такие вопросы важны, обычно пользуются BitBucket.
>несколько отстранившихся от участия в проекте разработчиков выразили желание вернуться к активной разработке в случае перехода на Git и GitHubТипичные Git-истерички. Главное не разрабатывать, главное - шашечки.
Не могу не согласится.
Профит можно получить и с истеричек, переезд на GH не такая уж большая цена.
А потом они заявят, что им форматирование кода не нравится и вообще проект на другом ЯП писать нужно и в любимой IDE.Что мешает участвовать в разработке и отсылать патчи напрямую разработчику или в меил лист?
> А потом они заявят, что им форматирование кода не нравится и вообще проект на другом ЯП писать нужно и в любимой IDE.Таких истеричек это 1% от github истиричек. Им уже ничем не помочь.
> Профит можно получить и с истеричекБеда в том, что и продукт получается соответствующим...
Типичный диванный аналитик, выражающий своё личное мнение абсолютно на пустом месте, без учета аргументов критикуемых
> Типичные Git-истерички. Главное не разрабатывать, главное - шашечки.Это ты типичный дебил, разработчики как раз от ненужных шашечек избавляются.
>gitНикогда не слышал. Чем оно лучше hg?
Шустростью.
Камень в огород Python?
Нет, камень в огород Mercurial. Git-то тоже местами не на Си, а на перле написан.
Ну так тем более в огород Python
> Git-то тоже местами не на Си, а на перле написан.сколько уже можно этот бред перепечатывать из треда в тред, git давно везде написан на Си.
https://github.com/git/git/
> C 44.1% Shell 34.3% Perl 8.5% Tcl 5.9% Python 2.6% C++ 1.8% Other 2.8%
а ты туда свою морду засунь и посмотри что именно там написано не на Си.
> а ты туда свою морду засунь и посмотри что именно там написано
> не на Си.https://github.com/git/git/blob/master/git-send-email.perl
https://github.com/git/git/blob/master/git-bisect.sh
https://github.com/git/git/tree/master/t
А, ну да, тесты, сборка и вся "обвязка" (для чего питоны с перлами и шеллскриптами очень неплохо подходят) – фигня! Это все от неосиляторства разработчиков гита!
Вот если бы гипнотоды разрабатывали, то тут уж прям ух ... !!Глубоконеуважаемый эксперт, вы уж определитесь:
> git давно везде написан на Си.Или все же – большая часть проекта, как бы, на "второсортых язычках"?
> Глубоконеуважаемый эксперт, вы уж определитесь:
>> git давно везде написан на Си.
> Или все же – большая часть проекта, как бы, на "второсортых язычках"?Ну тесты и обвязка - отдельная тема.
Так можно про любой Си проект сказать, что он написан ещё и на make и shell.
Например, nginx https://github.com/nginx/nginx/search
> Так можно про любой Си проект сказать, что он написан ещё и
> на make и shell.Теплое с мягким сравниваем?
А ничего, что у нас тут, как бы, далеко не хелоуворлд?https://www.openhub.net/p/git/analyses/latest/languages_summary
> C 163,305
> shell script 135,939
> Make 3,246...
> Например, nginx https://github.com/nginx/nginx/search
https://www.openhub.net/p/nginx/analyses/latest/languages_su...
> C 119,608
> Perl 24,710
> Make 139
> Autoconf 84
>> Git-то тоже местами не на Си, а на перле написан.
> давно везде написан на Си.Проспись, третье ж число уже! https://www.openhub.net/p/git/analyses/latest/languages_summary
C 43.6%
shell script 35.4%
Tcl 7.5%
Perl 8.1%
Python 1.9%
Make 0.9%
C++ 1.1%
[...]
>[оверквотинг удален]
>> давно везде написан на Си.
> Проспись, третье ж число уже! https://www.openhub.net/p/git/analyses/latest/languages_summary
> C 43.6%
> shell script 35.4%
> Tcl 7.5%
> Perl 8.1%
> Python 1.9%
> Make 0.9%
> C++ 1.1%
> [...]Ну ок, какая команда из набора "git *" написана на Tcl, или на Make?
Вот я делаю git clone - выполняется скомпилированный код на С.
git add, git pull и т.д. - тоже запускается бинарник из кода на С.
>>> давно везде написан на Си.
>> Проспись, третье ж число уже!
>> C 43.6%
>> shell script 35.4%
>> Tcl 7.5%
>> Make 0.9%
>> C++ 1.1%
>> [...]
> Ну ок, какая команда из набора "git *" написана на Tcl, илиНа тикле - на вскидку gitk. Не каждый день, но пользуюсь, спасибо, брат жив.
Угу, он не "git *". Но ты ж знвл и подстелил, да?
Подстели, не медля, под 35.4% shell-а!
Не отмоешься, не оправдаешься же. Да-а-а??> на Make?
Без Makefile-ов не будет ни одной команды "из набора "git *"". Неожиданно!
> Вот я делаю git clone - выполняется скомпилированный код на С.
Нет, без make-а не делаешь. </ох, и зачем я читал в словаре про double down>
pull до недавнего времени был солидной частью на шелле. переделали на c, чтобы под виндой меньше тормозило, да.
> git add, git pull и т.д. - тоже запускается бинарник из кода
> на С.Пользователи убунты, дебиана и еще кучи дистров с вами не согласны!
https://github.com/git/git/commits/7d722536dd86b5fbd0c0434bf...
> Based on git-am.shhttps://github.com/git/git/commits/7d722536dd86b5fbd0c0434bf...
> Based on git-pull.shЯ прокапитаню: переписали на "труЪ-языг" только к релизу 2.6, т.е. 3 месяца назад.
До этого, видимо, вкушали тормозной кактус!Ну и для нечитателей:
https://github.com/git/git/blob/master/git-send-email.perl (1543 sloc)
https://github.com/git/git/blob/master/git-submodule.sh (1202 sloc)
https://github.com/git/git/blob/master/git-stash.sh (571 sloc)
https://github.com/git/git/blob/master/git-rebase.sh (597 sloc)
https://github.com/git/git/blob/master/git-bisect.sh (644 sloc)
Вы пробовали или сравниваете по языкам на которых они написаны ?
Как ни странно по скорости hg не уступает, а местами быстрее, так что все дело в том как писать и что писать, посмотрите на http://pythonhosted.org/pyftpdlib/benchmarks.html например где по скорости и потреблению памяти python не только не уступает, но часто и превосходит ftp сервера на C.P.S. пользуюсь и git, и hg система команд в hg гораздо более целостная и понятная
Git действительно по-шустрее кажется. Сравнивал проект на hg и его же перенесённым в git. С git-ом и пушилось/пулилось быстрее, и update, merge, commit, diff на глаз быстрее работали в нём. Субъективно конечно.
Плюс, насколько я знаю, git изначально задумывался как фреймвокр для построения своей скв на основе некоторого набора операций. Поэтому он и более низкоуровневый (соответственно требует большей подготовки пользователя), чем hg и позволяет более низкоуровнего стрелять в ногу. Например, попробуйте сделать в hg мердж из 100 веток в одну одним коммитом. А git такое умеет, и ещё много что.
у меня вот "на глаз" прямо противоположные ощущения.
нисколько не сомневаюсь что в git можно сделать такое что потом самому будет тяжело понять что же ты сделал :). Он действительно более низкоуровневый, но интерфейс hg очень хорошо продумал, за годы использования всего хватало и за командами не нужно далеко ходить если что-то забыл, встроенной справки и названия команды более чем достаточно чтобы понять что она делает, в отличие от git, где имена многих команд и их аргументов континтуитивны, но это конечно не замечается, если уже привык.Не могу себе представить зачем нужно делать мерж из 100 веток в одну одним коммитом, а как потом разбираться с историей, как при понять из какой ветки изменения при разрешении конфликтов, 100 way diff ?
>[оверквотинг удален]
> будет тяжело понять что же ты сделал :). Он действительно более
> низкоуровневый, но интерфейс hg очень хорошо продумал, за годы использования всего
> хватало и за командами не нужно далеко ходить если что-то забыл,
> встроенной справки и названия команды более чем достаточно чтобы понять что
> она делает, в отличие от git, где имена многих команд и
> их аргументов континтуитивны, но это конечно не замечается, если уже привык.
> Не могу себе представить зачем нужно делать мерж из 100 веток в
> одну одним коммитом, а как потом разбираться с историей, как при
> понять из какой ветки изменения при разрешении конфликтов, 100 way diff
> ?101 + base
>git
>>Никогда не слышал. Чем оно лучше hg?Слышали про github-эффект? Так вот, это первые три буквы этого названия данного феномена.
Я конечно догадываюсь о чем ты. Но вот не задача, Google ни сном ни духом о твоем так называемом "github-эффекте".Очень хочется почитать как именно Github увеличивает популярность проекта. Возможно тогда и я переведу свой проект туда.
Не волнуйся твоим поделкам это не грозит.
Как и твоим.
> Как и твоим.мои поделки давно на гитхабе гниют.
Гниение тоже полезно. Подготавливает почву для следующих поделок.
> Google ни сном ни духом о твоем так называемом "github-эффекте".прочитай текст на логотипе, а потом посмотри, где у них репа
Такими темпами здесь скорее можно увидеть Google-эффект.
>>git
>>>Никогда не слышал. Чем оно лучше hg?
> Слышали про github-эффект? Так вот, это первые три буквыМой $searchengine-fu крепче, видимо, чем у коллеги выше, и я за 5^W10 минут нашёл три^Wнемного разных значений для этого _ярлыка_. Поэтому я ну**я не догадываюсь, о чем же это Вы.
1/ Какой то лы^Wумудрённый годами [и тоооннами книг на фоне!] дядька, рассказывающий про http://www.computer.org/csdl/mags/co/2015/05/mco2015050116.pdf + http://www.youtube.com/watch?v=sC9IQPC3Lh4 необразованных крестьян, постящих на хубик в поисках "а как же надо-то, в конце-то концов?". //Кто сказал Black Duck??
1.1/ "No matter what I’m looking for, all I need to do is a site search on GitHub [...] This is a tremendous thing for product managers, designers and entrepreneurs." http://www.nathanbuggia.com/posts/sabbatical/week-5/
1.2/ Гордый пейзанин - туда же, видимо. ""I call it the Github Effect: when I first opened up a Github account and began pushing code, it caused a significant upswing in my productivity due to the fact that my code was now visible to people other than just myself. It's about reputation and honor, on some level.
1.3/ Whoa?! ""Suffers from the GitHub effect, “I can share this so I will!”
2/ Какие-то бизнесы https://pbrisbin.com/posts/the_github_effect/ в поисках "надо ж кодеров нанять -- у нас же бизнес!?".
3/ Разработчик system-d и Ко.: "В интернетах всегда кто-то думает, что я не прав." //на гу-плюсике, туда ссылки нет.===One always finds nicer ways of solving a problem when reading through their code on @Github
[---]
Знатный наброс! Одобрям-с и поддержам-с. Тролинг ртутных -- впердё!!
> В остальном GitLab проигрывает и приходится выбирать между открытостью платформы или функциональностью/привычностью/сочетаемостью с другими проектами.а что есть такого у github, чего вам не хватает в GitLab? И если на то пошло, то надо сравнивать с GitLab EE, так как github таки платный. Хостинг только открытых проектов не рассматриваем.
> На поддержание своей инфраструктуры GitLab нужно много ресурсов
например? Мне хватает EC2 инстанса, с автоматическим бекапом. При использовании omnibus сборки - устновка/настройка/обновление занимает минуты. Хотя бывают косяки при обновлениях. Хотя лично сам за два года не наступал.
> в GitHub вся инфраструктура готова и неплохо справляется с разными DDoS.
все так любят писать это слово, хотя реально сталкивалось с ним пару людей. Ну ограничьте доступ с фиксированных ip. Да, не так удобно, но зато защитит от атак. Ну или можно воспользоваться тем же CloudFlare, если у вас минута простоя стоит 10k$+
> Почему-то в списке сервисов в проекте я вижу полторы страницы -- и Дрон, и Дженкинс, и Тимсити и прочее. Плюс вебхуки для всякой экзотики.в Gitlab CE 7.13.x не вижу Jenkins в упор - http://i.imgur.com/dt5LW5G.png
В 8.2.x картина аналогичная. Может не туда смотрю?
> интеграцию с другими ci-серверами они недавно совсем выпилили
> Можно пруф?думаю имелось ввиду это - "In GitLab 8.3, Jenkins integration using the GitLab Hook Plugin was deprecated in favor of the GitLab Plugin. The deprecated integration has been renamed to 'Jenkins CI (Deprecated)' in the project service settings. We may remove this in a future release and recommend using the new 'Jenkins CI' project service instead"
http://doc.gitlab.com/ee/integration/jenkins.html
Но это относится только к EE редакции и там лишь была перенесена настройка с одного места в другое
Безусловно полезно и удобно для CPython, но вредно для отличной СКВ Mercurial.
Скорее - смертельно для неё, хе-хе :-)
Нужно ли быть самым популярным чтобы продолжать развиваться, иметь пользовательскую базу и быть для ряда применений и обстоятельств лучшим выбором?Умерли ли все языки кроме JavaScript?
>и быть для ряда применений и обстоятельств лучшим выборомДля систем контроля версий лучший выбор это С, а уж никак не Python.
JS ЯП, а мы говорим про тулинг и да старому тулингу на смену приходит новый. Был Grunt сейчас практически везде Gulp в новых проектах.
> Умерли ли все языки кроме JavaScript?А что в браузере появилась нативная поддержка других языков?
А что, кроме браузеров ничего не осталось?
А что, нативная поддержка всегда лучше не нативной? (Elm, ClojureScript)
Лично мне будет достаточно того, чтобы оно мне случайно не попадалось. А где там онобудет использоваться для частных рпоектов, как Fossil тот же - неважно.Я даже не то, чтобы сильно ненавидел Mercurial - просто считаю, что у него нет достаточных преимуществ перед Git чтобы терпеть ещё одни распространённый версионник. Это такая штука, в которой чем больше унификации - тем лучше.
А с джаваскриптом я бы не сравнивал. Наоборот - он популярен (и жив вообще) только потому, что принудительно держит монополию в ставшей популярной по совсем другим причинам нише. В результате ему и стандарт, и реализацию подтянули, и разработчиков набралось. Сложись сейчас в вебе ситуация, аналогичная VCS (допустим, окажись во всех браузерах поддержка полноценного Питона) - очень большой вопрос, выдержит ли JS конкуренцию.
> Это такая штука, в которой чем больше унификации - тем лучше.Вот такие люди, не слыхавшие о стандартизации, и обижаются потом
на "школие". Загнобить альтернативы - единственный путь развития!Windows-децтво торчит у вас отовсюду.
Нет.Никто их не гнобит.
Альтернативы - пусть копошатся тихо в своём углу, как Fossil и Darcs. Или Haskell какой-нибудь. Или мой любимец Notion WM. Или... да вагон таких. Если мейнстрим сильно начудит - о них вспомнят. Плюс хорошие идеи из них будут потихоньку перетаскивать в мейнстрим.
А вот иметь несколько конкурирующих "мейнстримных" открытых продуктов - это бред почти всегда, особенно для (D)VCS. Это ж не window manager, где никому за пределами твоего десктопа не важно, чем ты пользуешься.
> Никто их не гнобит.
> Альтернативы - пусть копошатся тихо в своём углуПроходили это уже, аж веке в XIX-м. Резервации там разные,
права индейцев...Страшно то, что гнобят альтернативы - совершенно не по техническим
причинам. В тексте PEP черным по белому - достоинств у Git нет.Bibucket даже не вспомнили (раз уж им так github-workflow втемяшился)...
> Плюс хорошие идеи из них будут потихоньку перетаскивать в мейнстрим.
А плохие идеи из мейнстрима кто будет доставать? У вас же
не плановая экономика - капитализьм, конкуренция, свободный рынок (тм).> А вот иметь несколько конкурирующих "мейнстримных" открытых продуктов - это бред почти
> всегда, особенно для (D)VCS.А то. Впаривать удобно, когда все ходят ровными рядами. Наплодили плохие
дяди интернет-стандартов, вот у них по десятку веб-серверов развелось. Непорядок -
не дают эффективным менеджерам развернуться! Ну ниче, гитхабчик вам запилит все.
> У вас же не плановая экономика - капитализьм, конкуренция, свободный рынокТкни пальцем в средней юности девелопера - попадешь в латентного троцкиста.
Т-щ следователь, ви че мне шьете?ЗЫ:
Ранней юности девелоперы, надо полагать, этими
марксами голову уже вовсе не забивают? Монополия - эт
игра такая, да детка?
А плохие идеи - доставали и достают. Что понемногу рефакторят/депрекейтят, что в мажорных версиях ломают. А когда этого не происходит то в какой-то момент "вдруг" выстреливает гадкий утёнок, который тихо без хайпа развивался и дошёл-таки до кондиции, делов-то. Либо форк вырастет.А гитхабчик - ну да, плохо. Но, в конце концов, это не в гугле документы держать - локальных версий вагон. Будет чудить - смигрировать не то, чтобы очень сложно. Вот поэтому и чудить не будет, собственно.
> А плохие идеи - доставали и достают. Что понемногу рефакторят/депрекейтят, что в
> мажорных версиях ломают. А когда этого не происходит то в
> какой-то момент "вдруг" выстреливает гадкий утёнок, который тихо без хайпа развивался
> и дошёл-таки до кондиции, делов-то. Либо форк вырастет.Что-то эта картинка сильно напоминает сказошные дали про "конкуренцию",
"свободный рынок" и проч. пое***нь от прихватизаторов. А экономические
реалии всегда вырисовывают монополии, убить которые можно только
с помощью более-менее честного внешнего регулятора.> А гитхабчик - ну да, плохо. Но, в конце концов, это не
> в гугле документы держать - локальных версий вагон.А вот если к практике. Хочу я смигрировать с GitHub на GitLab, че делать?
Во что это выльется, по пунктам?
> Страшно то, что гнобят альтернативы - совершенно не по техническим причинам.В данном случае никакого гнобления нет, проект решил ориентироваться на большинство которого оказалось раз в 20 больше. Получилось так потому что hg не понравился разработчикам в виду различных причин, и технических в частности.
> В тексте PEP черным по белому - достоинств у Git нет.
Зачем нагло врёшь, в тексте этого нигде не написано. Сказано что этот вопрос вообще не рассматривается.
>> Страшно то, что гнобят альтернативы - совершенно не по техническим причинам.
> В данном случае никакого гнобления нет, проект решил ориентироваться на большинство которого оказалось раз в 20 больше.Ну да. Бездумный уход на альтернативное решение - это не гнобление, вы чо.
Нет такого гитхабчика, куда по OpenID со вконтактиков школие
пускают? А то надо-ть сказать разработчикам - пропускают контингент "контрибьютеров".> Получилось так потому что hg не
> понравился разработчикам в виду различных причин, и технических в частности.Ни слова там про технические причины, утрись.
>> В тексте PEP черным по белому - достоинств у Git нет.
> Зачем нагло врёшь, в тексте этого нигде не написано. Сказано что этот
> вопрос вообще не рассматривается.There are really only two real options for this, Mercurial and Git. Between the two of them the technical capabilities are largely equivilant. (ц)
Жабе опять рассказывать по гуглоперевотчек?
> Проходили это уже, аж веке в XIX-м. Резервации там разные, права индейцев...Живу в 30 км от резервации индейцев, слежу за этой темой и всячески интересуюсь. Чувак, ты даже близко не представляешь о чём идёт речь. Настолько, что одна эта ремарка выворачивает смысл твоего коммента наизнанку.
>> Проходили это уже, аж веке в XIX-м. Резервации там разные, права индейцев...
> Живу в 30 км от резервации индейцев, слежу за этой темой и
> всячески интересуюсь.И за какой период времени вы полагаете у себя "представление о чем идет речь"?
Для справки, чуть более полвека назад в некоторых штатах даже
смешанные браки были незаконны. "Негров линчуют" - это на пустом месте.
Мечтают ли парикмахеры об унификации размеров и формы голов?
> допустим, окажись во всех браузерах поддержка полноценного Питона - очень большой вопрос, выдержит ли JS конкуренцию.Вопорс никакой, конечно, выдержит. Питон, с одной стороны, громоздкий (тянет свои батарейки) и ничего не может предложить существенно лучшего по сравнению с JS (в контексте оптимизации по памяти и cpu). А сдругой подкидывает на вентилятор проблемы с отступами и своим фашистким PEP8.
Можно сделать иную замену, совсем Ъ и с учётом всех проблем, но такой альтернативой просто не захочет пользоваться весь текущий контингент веб разработчиков.
> у него нет достаточных преимуществ перед Git
У hg есть вполе существенные недостатки из-за чрезмерной технической переусложнённости в ненужных местах (вынос традицонного функционала в плагины из-за чего VCS теряет консистентность, мудотень с разными видами веток) и попыткой сохранить видимую совместимость с древними VCS (нет понятия индекса и команд работы с индексом, не развито редактирование истории и т.п.). git устроен проще и при этом более функциональный.
Ну, под "полноценным питоном в браузерах" и подразумевалось, что все имебщие смысл батарейки оказываются в браузере. А лучшее - как минимум, он может предложить не только асинхронную модель, которая на самом деле не нужна в 95% случаев, но JS по-другому не умеет. А вот в питоне есть кооперативная многозадачность, например.А вот "совсем Ъ" как раз победить не может ну просто потому, что умных мало, а кода надо писать много. Тут, кстати, ещё вопрос, был бы в вебе PEP8 во вред или на пользу.
hg я смотрел совсем поверхностно, и насчёт технических недостатков не в курсе. Просто не вижу ничего хорошего в "конкуренции мейнстримов" в свободном софте, особенно там, где это влияет на командную работу.
> А лучшее - как минимум, он может предложить не только асинхронную модель, которая на самом деле не нужна в 95% случаев, но JS по-другому не умеет. А вот в питоне есть кооперативная многозадачность, например.Ты это так пишешь будто в этом есть какая-то заслуга питона. Не прошло и десяти лет как наконец таки прикрутили через задницу async и корутины, да и то всё это в самом последнем релизе которвый никуда ещё не доехал. В таком виде эти фичи прикручиваются к любому подобному ЯП и для JS это всё тоже есть.
> Тут, кстати, ещё вопрос, был бы в вебе PEP8 во вред или на пользу.
PEP8 несёт одназначный вред т.к. многие моменты в нём достаточно спорные. В других языках такие вопросы отдаются на откуп разработчкиам, но с питоном всё иначе - с какого-то будуна язык получил один единственный, неправильный, стиль кодирования. Теперь больные на голову апологеты доводят всё до абсурда пропихиванием этого стандарта безусловно во многие редакторы. Например, в VIMе с недавнего времени это гогно перетирает все стандартные настройки (например, настройки обратоки TABов) и это недарозумение овощей приходится специально вырезать. Такое поведение совсем не идёт на пользу популяризации языка.
>> Тут, кстати, ещё вопрос, был бы в вебе PEP8 во вред или на пользу.
> PEP8 несёт одназначный вред т.к. многие моменты в нём достаточно спорные. В
> других языках такие вопросы отдаются на откуп разработчкиам, но с питоном
> всё иначе - с какого-то будуна язык получил один единственный, неправильный,
> стиль кодирования.У данного языка - нет никакого "стиля кодирования". Технически, это стандарт
для CPython - реализации языка и его стандартной библиотеки. Следование других
ему - совершенно опционально, хотя многие в той или иной степени следуют.Спорные вещи там, действительно, наверно есть (от стандартов GNU есть
куда больше оснований плеваться, ИМХО) - но не настолько чтобы
вопить про ужос. 99.9% за то, что полтора разработчика какого-нить
среднего левого проекта - выдумают много хуже. PEP8 - фашизм хороший, ламповый.> Теперь больные на голову апологеты доводят всё до абсурда
> пропихиванием этого стандарта безусловно во многие редакторы.Что плохого в поддержке определенного стиля кода редактором? Python - не
последний язык, чтобы стилевые соглашения для его разработки были неважны.> Например, в VIMе с
> недавнего времени это гогно перетирает все стандартные настройки (например, настройки
> обратоки TABов) и это недарозумение овощей приходится специально вырезать.
> Такое поведение совсем не идёт на пользу популяризации языка.Может это проблема детей, которые используют VIM и/или пишут для
него кривые расширения?
Фашизм одного единого стандарта кодирования вам нравится.
Фашизм одного единого VCS вам не нравится.
Вы уж определитесь.
Иначе это смахивает на двойные стандарты - "когда стандартом выбирается то что мне нравится, я за стандарты, а когда не то - тогда за конкуренцию".
> Фашизм одного единого стандарта кодирования вам нравится.Фашизмом можно обозвать что угодно, см. Вукраина.
Ну так уж получилось, что любой проект вырабатывает для себя стандарты
кодирования. Фашизмом можно назвать разве что случай, когда такие стандарты
агрессивно навязываются вне проекта. Но это не про PEP8 - это про
фантазии о нем некоторых возбужденных граждан.> Фашизм одного единого VCS вам не нравится.
Мне не нравится, что игнорируя технические доводы - начинают менять
шило на мыло, когда все итак работает. Просто потому что модно.
Слово "фашизм" в контексте VCS употребил не я - к употребившему и вопросы задавайте.> Иначе это смахивает на двойные стандарты
Скорее, на тотальное недопонимание.
Прекрати, грёбанный виндузятник98, руками разбивать абзац на строки.> У данного языка - нет никакого "стиля кодирования"
Де факто он есть и это как раз PEP8.
> Технически, это стандарт для CPython - реализации языка ...
> от стандартов GNU есть куда больше оснований плеваться, ИМХОЧто за бред несёшь, PEP8 к Си никакого отношения не имеет, GNU стандарта для питонокода нет.
> Прекрати, грёбанный виндузятник98, руками разбивать абзац на строки.Phys Rev расскажи как удобно читать длиинные простыни текста...
>> У данного языка - нет никакого "стиля кодирования"
> Де факто он есть и это как раз PEP8.Дурачок, это внутренний стандарт для разработки конкретной реализации языка.
This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.
Если у детей все еще трудно с переводом, я могу рассказать про
Google Translate.>> Технически, это стандарт для CPython - реализации языка ...
>> от стандартов GNU есть куда больше оснований плеваться, ИМХО
> Что за бред несёшь, PEP8 к Си никакого отношения не имеетPEP7 - имеет, причем прямое. PEP8 - аналог для Python-кода в Python.
> GNU стандарта для питонокода нет.
И что?
> Дурачок, это внутренний стандарт для разработки конкретной реализации языка.Дебил безмозглый, реализация питона называется CPython и написана на Си.
PEP8 стандарт для батареек и фактически старнадр для почти всего остального кода написанного на питоне.
> PEP7 - имеет, причем прямое. PEP8 - аналог для Python-кода в Python.
Отлично, до дебилёныша начинает доходить что он морозит бред почти в каждом предложении. Только вот не хватает силы воли остановиться, потому в бреде так неожиданно выскакивает PEP7.
>> Дурачок, это внутренний стандарт для разработки конкретной реализации языка.
> Дебил безмозглый, реализация питона называется CPython и написана на Си.Стандартная библиотека - является частью этого проекта. Рад что
для вас это новость - вон сколько в жизни чудес!> PEP8 стандарт для батареек
Ну да, хотя де-факто - для всего python-кода с python.org, такой
код там не только в Lib.> и фактически старнадр для почти всего остального кода
> написанного на питоне.А это - продолжающееся вранье. Тут дело совершенно добровольное, спрашивайте
с разработчиков конкретных проектов.
Не то, чтобы заслуга питона - но в JS по-другому не бывает. Но насчёт последней верии не понял - там, вроде, кооперативная многозадачность с момента появления генераторов делается. насчёт I/O не знаю, правда - далёк я от питона.
> А сдругой подкидывает на вентилятор проблемы с отступамиА какие у вас проблемы?
> и своим фашистким PEP8.
PEP8 - абсолютно опциональная штука ваапще. А что там
конкретно фашистского, в сравнении с любым другим аналогом?
> PEP8 - абсолютно опциональная штука ваапще.Ну вот достаточно большая кучка питоноовощей так не считает, смотри мой комент выше.
>> PEP8 - абсолютно опциональная штука ваапще.
> Ну вот достаточно большая кучка питоноовощей так не считаетПричем тут что кто "считает" - это дело факта.
Проблема или вернее ситуация в несколько другом. Когда-то было что не очень понимали зачем вообще держать код в каком-то хранилище. Был корпоратив с локами и криками на весь этаж "кто залочил мой модуль". И были одиночки с вызовом архиватора из скрипта. Одни хотели контроля, другие простоты. Потом были CVS, SVN и куча всякого. Но так или иначе люди понимали что хотели получить от системы и выбирали таким путём. Был определённый workflow и система должна была приспосабливаться к нему. Линукс показал, что централизованные системы не удобны для некоторых случаев. К этому времени начали развиваться DVCS. Появление git безусловно было важной вехой. А сколько было после непонимания всей этой децентрализованности. Но Линус выступил, показал, похвалил и вроде приняли. Потом развиваются хостинги с полным фуршетом. Отлично это даже удобно.
А теперь уже перестают "выбирать" систему, думать о workflow. Всё уже выбрано оптимизировано осталось только заглотить, даже переваривать не надо. Git сложен для начинающих! Да вы что, теперь не один программист в этом не признается. Большинство будет с пеной доказывать, что git это наилучшая система и даже единственно возможная, но не зная даже десятой части его команд. А зачем, есть IDE-интеграция и всякие графические клиенты?
Так ли важно теперь, что за консольный клиент устанавливается и его команды.
Для большинства это просто какой-то клиент гитхаба, никто не будет выбирать VCS, никто не будет выбирать workflow. Всё уже выбрано и утверждено.
Чтож git это сейчас система для новичков. Чтобы выбрать что-то другое требуется гораздо больше опыта и понимания.
> А теперь уже перестают "выбирать" систему, думать о workflowДумать - это вообще моветон, мерзким waterfall попахивает!
А workflow это ж бизнес-процессы, их следует отряхнуть с agile-ног, иначе ночью придёт COBOL и съест.
Можно подумать, что в agile нет workflow. Он, как бы, везде и всегда есть, если не о хобби говорить, вопрос только - насколько вменяемый и осознанный. Но agile - да, задолбал несколько.
"Вменяемый и осознанный" is not an option anymore. Welcome to the wonderful pop-culture-driven world of modern software development.
Вообще-то это нормальная ситуация перехода от ремесла к промышленности. Всё больше уровней стандартизированы, всё больше задач имеют готовые решения. И в большинстве случаев потери из-за не идеальной оптимальности этих решений будут меньше, чем затраты на поиск идеального для себя варианта.
Что ты заладил со своей стандартизацией. Нет такого нигде в промышленности, коммерческих VCS существует больше чем опенсорсных и так практически с любым инструментом в индустрии.
Люди, какие же вы все тут счастливые.
Радость и любовь друг к другу так и переполняют вас.
И вас с праздником Владимир Владимирович, верните доллар по 32.
> И вас с праздником Владимир Владимирович, верните доллар по 32.Ну по 72 уже ввернул, к концу года доверну до 92-х
Как обычно, модераторы не читают что постят... Где "приняли
решение"? Обсуждение только идет, PEP в статусе Draft...ЗЫ: Относительно перехода - ничего странного. Количество школия
среди "основных разработчиков" - уже способно сделать вас грустным (простой
пример - "rationale" обсуждаемого PEP, где черным по белому написано что
делается переход ради тех, кто банально не желает или не умеет учиться).Пропал калабуховский дом окончательно, короче.
Черт, действительно драфт. Тоже мне, новости.Ну, ждём - может, таки пройдёт. В VCS зоопарк неуместен.
> Как обычно, модераторы не читают что постят... Где "приняли
> решение"? Обсуждение только идет, PEP в статусе Draft...Тем сообщением в списке рассылки Brett Cannon как раз и объявил о решении перехода на Git/GitHub и намерением обсудить технические детали этого перехода. Пока эти детали не утверждены PEP будет в статусе Draft, но сам переход уже рассматривается как состоявшееся решение.
> Тем сообщением в списке рассылки Brett Cannon как раз и объявил о
> решении перехода на Git/GitHubНа что ему резонно возразили, что он не главный тут объявляльщик. Действительно,
переход на Git - достаточно несомненный, а вот с GitHub/GitLab - непонятно. У
последнего - много сторонников.Впрочем, GitHub-мартышки - победят, скорее всего. Жаль.
О да было бы забавно наблюдать как разрабатывают питон используя руби.
так они оба -- и github и gitlab -- на rails написаны.
github уже давно не на рельсах.
да и gitlab настроен мигрировать с них в обозримом будущем.что внутри гитхаба уже давно точно неизвестно и не берусь утверждать, что там рельсов не осталось совсем. вы знаете больше?
Если бы не знал инсайд, то не говорил бы что рельс нет.
припозднились что-то
Давно пора
подождем когда заблокируют гитхаб
