Алан Дей (Allan Day), входящий в совет директоров GNOME Foundation (https://www.gnome.org/foundation/), выставил (http://www.mail-archive.com/desktop-devel-list@gnome.or...) на рассмотрение сообщества предложение по переводу разработки на свободную платформу GitLab (https://about.gitlab.com/), которую планируется развернуть (https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/) на собственных серверах в инфраструктуре GNOME.
Текущая инфраструктура, в которой используется cgit и система отслеживания ошибок Bugzilla, существенно устарела, не удовлетворяет современным потребностям, имеет проблемы с юзабилити и не предоставляет должных возможностей по рецензированию кода. Ожидается, что внедрение GitLab устранит имеющиеся проблемы, позволит увеличить эффективность разработки и привлечёт новых участников в проект. Отмечается, что многие новые разработчики привыкли к GitHub и отдают предпочтение данной платформе, но использование GitHub в GNOME недопустимо в силу её проприетарного характера, в то время как платформа GitLab достаточно близка по возможностям и является свободным ПО.
URL: http://www.mail-archive.com/desktop-devel-list@gnome.or...
Новость: http://www.opennet.me/opennews/art.shtml?num=46558
Уважаю гномеров, молодцы.
> Уважаю гномеров, молодцы.неуважаю гномеров, но гитлаб - молодцы, если сумеют заполучить такой проект.
Gerrit && cgit && Jenkins = быстро, бесплатно, код удобнее ревьювить, можно настроить любые политики для ревью благодаря встроенному интерпретатору Пролога.
Они видимо не в курсе сколько этот монстр кушает ресурсов.
Ну вы то в курсе, просветите нас)
конечно в курсе. ДОФИГА
И не забывать ресурсы на стороне клиента: куча трафика, куча памяти браузера.
Может сейчас ситуация лучше, но 4-5 лет назад был полнейший треш.
Установили на виртуалке с 2гб памяти, после первого апдейта запустился только после апа до 3гб, после 2го апдейта - пришлось апнуть до 4гб, в итоге дошли до 12гб.
Ни триггеры, ни интеграции с СИ, ни лдап или других фишек не юзалось, он был поднят ради гит сервера + веб интерфейса на небольшую команду.
Сейчас на старте дела обстоят примерно так: просто установить и не пускать пользователей - почти полностью кушает одно ядро и несколько гигов оперативы. С пользователями вообще пичаль. Тем не менее кряхтит, тупит но вроде работает.
Кстати апгрейд все так же квест, как и раньше: что-нибудь, да отвалится.
юзайте https://kallithea-scm.org , оно не жрёт столько памяти
Оно недостаточно похоже на гитхаб, молодняк будет пугаться.
А вообще какая разница, сколько оно жрёт сейчас, если оно всё равно на питоне? Будет развиваться — распухнет очень быстро, не будет — и что с него толку?
Вот не на питоне
https://gogs.io
> Вот не на питоне
> https://gogs.ioплюсую за gogs.
gogs -- самое простое в развертывании, эксплуатации решение, к тому же наименее ресурсоемкое и тормозное на порядок. готово к использованию сразу после скачивания -- запускаем всего 1 исполняемый файл и вуаля!
Только в плане функционала ему до gitlab очень далеко. Понятное дело, что встроенный CI или тем паче Docker registry не всем нужны, просто хочу напомнить агитаторам за gogs, что эти два продукта относятся к совершенно разным весовым категориям.
Или gitea (https://try.gitea.io/).
Это форкнутый gogs. Причина форка банальна: "дайте тоже порулить" (https://blog.gitea.io/2016/12/welcome-to-gitea/ )
> юзайте https://kallithea-scm.org , оно не жрёт столько памятиДва чая этому господину
Оно такое Г! что ты _захочешь_ прикупить памяти под GitLab ;-)
Конечно ощутимо больше cgit, но, думаю, поменьше багзиллы. Учитывая тенденцию к переписыванию на go, сильно жиреть в будущем не должен, скорее наоборот.
На Go в GitLab написаны только всякие фронтэндеры/кешеры/runner'ы для CI. Основная кодовая база всё-таки на Ruby, но тормозит она не так страшно, как привыкли все описывать.
тормозит не сильно, но памяти кушает все, что дают. им прийдется вполне раскошелится на ресурсы, чтобы низенько лететь с гитлаб
Переведут багзиллу в ro — высвободят ресурсы.
Да не, для мелких проектов и на 1 GiB рамы всё летает (без учёта базы). Для больших, конечно, попросит больше, но и GNOME не бомжи на окраине - ресурсов найдут.
gitlab 9.1, живет на 2 гигах, работают 30 человек. Что я делаю не так?
> gitlab 9.1, живет на 2 гигах, работают 30 человек. Что я делаю
> не так?Сотни репозиториев, работает порядка ста человек, жрёт около 8 гигов. Много, конечно, но не так чтоб прям разориться на оперативке.
> GitLab ... Основная кодовая база всё-таки на Ruby, но тормозит она не так страшно, как привыкли все описывать.Ну уж нет. Каждый переход обрабатывается от секунды до нескольких. Ждать зверею просто.
И это при том, что нехило ресурсов мы на виртуалку гитлабу выделили.
И это при том, что у меня Core i7 на рабочей машине, и все другие интерфейсы просто летают в соседних вкладках.
gnome и ресурсы -- такие ресурсы и gnome.
кто-нибудь, расскажите им, что оперативная память конечна и процессор имеет ограниченные возможности
last pid: 89105; load averages: 0.32, 0.16, 0.11 up 179+07:32:53 16:32:58
59 processes: 1 running, 58 sleeping
CPU 0: 1.1% user, 0.0% nice, 0.0% system, 0.0% interrupt, 98.9% idle
CPU 1: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle
CPU 2: 0.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.3% idle
CPU 3: 0.7% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.3% idle
Mem: 414M Active, 2515M Inact, 576M Wired, 192M Buf, 419M Free
Swap: 4096M Total, 151M Used, 3944M Free, 3% InuseНа тазике gitlab+redmine (решил всю рубиновую поепень на один тазик)
nginx+passenger+redis+workhorse(к сожалению теперь оно у них обязательное)+postgresqlстартует это всё с 20сек задержкой но работает норм. и я бы не сказал что это монстр.
опять же посмотрите в сторону gitprep.
>и я бы не сказал что это монстр.Да по нынешним временай и GUI бы с ним.
Обновлять его - вот где лотерея!
>>и я бы не сказал что это монстр.
> Да по нынешним временай и GUI бы с ним.
> Обновлять его - вот где лотерея!1. обновляем (не из-под рута!)
sudo -u git git pull2. проверяем внутренними средствами gitlab/ruby
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
при необходимости доустанавливаем необходимое:
sudo -u git -H bundle install3. рестартуем gitlab
service gitlab restart
для мажорных обновлений возможны ещё две операции:
апдейт структуры БД
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=productionрекомпил ассертов
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=productionНекоторые гемы (gems) линкуются с системными библиотеками, и после апгрейда системных библиотек могут сломаться.
Такой gem нужно:
1. удалить
sudo -u git -H bundle exec gem uninstall charlock_holmes
2. переустановить
sudo -u git -H bundle installЗЫ подразумевается что вы сидите на git-версии и умеете переключатся на бранчи новых версий
попробовали бы gogs, по фичам конечно маловато но зато кушает очень мало
Они не в той весовой категории чтобы "пробовать". Пробуйте сами.
а какая нужна весовая категория ?
Ну там Budgie какой-нибудь. MATE или Cinnamon, я думаю, тоже подойдут.
это всё очень хорошо, но вы можете конкретнее сказать чего не хватает для попадания в нужную категорию ?
Например комментарии к ревью кода.
Они его вроде как рассматривали.
> Текущая инфраструктура, в которой используется cgit и система отслеживания ошибок Bugzilla, существенно устарела, не удовлетворяет современным потребностям, имеет проблемы с юзабилити и не предоставляет должных возможностей по рецензированию кода.Ммда. Т.е. самый сложный (во многих смыслах) проект (я имею в виду Linux kernel) вполне себе обходиться без этих рюшечек. Как и многие другие системообразующие проекты. А чем более bloatware, тем больше внимания "usability in codereview" и мультимедийным возможностям в bugtracker.
В сложные проекты могут только люди которые могут хоть как, хоть где и хоть во что.
// ваш КО
> Ммда. Т.е. самый сложный (во многих смыслах) проект (я имею в виду Linux kernel)тот, кто вам эту лапшу повесил на уши - обманщик и нехороший человек.
линупc-кернел - чрезвычайно простой проект. Именно как проект. При этом он всегда крайне мерзко относился к человеческим ресурсам, неоднократно хороня чужую сложную и нужную работу в мусоре и личных хотелках. А некоторые нетривиальные вещи в нем - сделаны отдельными командами, использовавшими вполне современные средства коммуникации и командной разработки, при _активном_противодействии_ "гения менеджмента".Если вы хотите посмотреть на сложный проект - попробуйте исправить что-нибудь мелкое в поведении mozilla.
Под "сложным проектом" я имел ввиду "технически сложным". Mozilla --- переусложнённый проект.
Классика опеннета — заминусовали парню самый адекватный коммент :)))
И где там адекватность? Линукс-ядро с кучей распределённой разработки - простой проект? А успех менеджмента определяется результатом. Повсюду мы видим именно линукс-ядро, а не что-то другое. Вывод - менеджмент хороший. А то, что автор коммента линукс (и свободный софт вообще) терпеть не может и на любой чих рекламирует винду и прочую проприетарщину - к нему любви ни разу не добавляет.
все нормально - если этой пары минусов нет, значит, я опять ляпнул что-то не то. ;-)классика опеннета - это считать линукс "сложным проектом", в разговоре, где речь о монстрах, это вот да.
Что, кроме прочего, в очередной раз как бе говорит нам об общечеловеческой пользе этого вашего опенсорсе в принципе - любой человек, на деле пытавшийся что-то поменять в ведре линукса и в чем-нибудь размером хотя бы с мазилу (и Б-же упаси нас быть вынужденными что-то чинить в гноме) - совершенно не нуждается в моих доказательствах и разъяснениях. Как и любой, кто пытался либо потом сдать эти свои поделки в апстрим, либо отслеживал судьбу чужих - и проделывал то же самое в проектах с нормальными средствами управления.
Похоже, Вы не имели в этой области не то, что положительного опыта, а опыта вообще. А я имею. (И в энтерпрайзе тоже, т.е. есть с чем сравнивать).Но поробуем не уходить от main topic.
Проекты, обвешанные вспомогательными "рюшечками" (вроде того же gitlab) концентрируются на социальной инженерии, а не на технической. Инженерная составляюща окаывается слабой --- можно поразглядывать качество коммитов в проектах, где оперируют кодом в основном через средства gitlab (github, jenkins, etc.), и тех, где не концентрируются на обвязках.
> А я имею. (И в энтерпрайзе тоже,если линукс для вас "сложный проект", то про ваш ентер-прайс я вообще ничего знать не хочу.
мой "ентрепрайз" обходился svn и trac (пачкой trac'ов, в виду неумения оного нормально работать больше чем с одним репо) плюс парой омерзительных конструкций для тестирования (мда, кто там страдал по двум гигам для несчастного гитлаба? 12 для тестовой жабьей морды не хотите ли?) - и, в отличие от линyпсов, за несколько лет я так и ниасилил более-менее разобраться хотя бы просто в архитектуре (не то чтоб, конечно, и хотелось бы, но я и про линуксы предпочел бы ничего не знать, а на эту хрень ведь была еще и документация...зачеркнуто, вики-мусорка, на линукс и того нет), не то что что-то хотя бы мелкое исправлять.
"Плохому танцору багтрекер мешает"
где можно почитать про разницу в проприетарности между gitlab и github ?
> где можно почитать про разницу в проприетарности между gitlab и github
> ?Читай прямо здесь, строчкой ниже.
CitLab CE — свободный, GitHub во всех инкарнациях — проприетарный.
> CitLab CE — свободныйfast-forward merges в CE они отключили, чтоб он ещё более свободный был?
>> CitLab CE — свободный
> fast-forward merges в CE они отключили, чтоб он ещё более свободный был?Где его там отключили? В веб-морде, что ли? Отродясь через неё ничего не мержил. Ну хочешь — включи, исходники-то есть.
При этом есть не свободная версия с кучей плюшек: https://about.gitlab.com/free-trial/
Гитхаб же для опенсорс проектов полнофункционален и бесплатен.
gitlab.com тоже полнофункционален и бесплатен для опенсорс-проектов.
да, там ынтырпрайзная редакция.
Вот здесь в комментах их сравнили. Кратко: на гитхаб ля больших проектов, состоящих из горы репозиториев, неудобен, имеет ещё ряд недостатков плюс они хотят свободное, а не просто бесплатное. Что правильно, конечно.
Исходников github нет, его нельзя поставить на свой сервер/инстанс в облачном окружении IaaS
Можно, но код закрыт. GitHub Enterprise.
GitLab можно на своём оборудовании развернуть. GitHub - нет.
> GitLab можно на своём оборудовании развернуть. GitHub - нет.Не так давно тут была новость про дыру, найденную в ынтырпрайзном гитхабе, который именно что ставится на железо клиента.
Ну ок, более полно: GitLab можно свободно скачать и развернуть на своём оборудовании, GitHub - предлагаются диски диски для ВМ (с возможностью заливки в Azure и т.д.), с уже предустановленным по количеству купленных лицензий сервисом.
Вот тут вроде про это https://help.github.com/enterprise/2.9/admin/guides/installa.../
Всё равно недостаточно полно, ибо существуют GitLab CE и EE.
> Всё равно недостаточно полно, ибо существуют GitLab CE и EE.А вот за ЕЕ будь добр и заплати в УЕ, что, в общем, логично и вышесказанного не отменяет :)
можно же
https://enterprise.github.com/features
Согласно санкциям гитхаб дожен быть не доступен в Крыму, Северной Корее, Иране и ещё у парочки врагов человечества. Как на самом деле обстоят дела не знаю.
Санкции запрещают коммерческие отношения с этими территориями. Под бесплатным акком хоть обкомиться, но но захочешь купить подписку для приватных реп, тут-то тебя и развернут
Bugzilla реально старьё. Захочешь баг оформить и испугаешься, так и не сделав этого. Новичков пугает.
> Bugzilla реально старьё. Захочешь баг оформить и испугаешься, так и не сделав
> этого. Новичков пугает.А может это и хорошо? Если уж bugzill'у не потянул, то и контрибъютор соответствующий --- никакой пользы окромя вреда.
Чтобы описать, что происходит или высказать пожелание - не так много надо, тем более это всё же безнадёжно гуёвый проект. А вот для списков рассылки для разработчиков - в точку был бы аргумент.
Гитлаб... эээ, небезопасен. gogs - глобально и надёжно.ps. ПРЕДУПРЕЖДЕНИЕ: В сообщении используется ненормативная лексика.
Пожлуйста откорректируйте сообщение, воздержитесь от острых высказываний и несодержательных комментариев, проявите уважение к собеседнику.
Выражение, на которое сработало предупреждение: 'р_е_ш_е_т_о'
Пруфы будут?
под новостью 6 ссылок. из них 3 - доказательства
Это доказательства того, что у них есть программа bug bounty, и что она эффективна. А код gogs подвергался какому-нибудь стороннему аудиту?
> система отслеживания ошибок Bugzilla, существенно устарелаКакая им разница, где писать won't fix и заставлять ждать очередной переписанной новой версии очередного кривого компонента гнома?
> gitlab 9.1, живет на 2 гигах, работают 30 человек. Что я делаю не так?если там один коммит в день - оно и понятно, так и 300 человек сможет работать.
>> gitlab 9.1, живет на 2 гигах, работают 30 человек. Что я делаю не так?
> если там один коммит в день - оно и понятно, так и
> 300 человек сможет работать.Народ тут пишет, что гитлаб триллион памяти кушает. Про людей и коммиты не пишет. Немудрено, что первый вопрос, который возникает "о чём вы говорите, работает на X гигах без проблем".
gitlab'овские процессы, в KiB. VSZ, RSS42373728 5881380
Коммитов мало, объем репозиториев --- ну, тоже довольно скромный.
Метод установки гитлаб меня позабавилcurl -sS htt ps://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
Что, неужели так и делают гореадмины? Непонятно какой скрипт под судо запускают? 😁
Строчкой ниже> If you are not comfortable installing the repository through a piped script, you can find the entire script here and select and download the package manually and install
в виртуалку на "посмотреть", почему бы и нет?
> Метод установки гитлаб меня позабавил
> curl -sS https: //packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
> | sudo bash
> Что, неужели так и делают гореадмины? Непонятно какой скрипт под судо запускают?а что запускающий этот скрипт дальше собрался запускать мегатонного монстра, от которого будет зависеть вся разработка его лавочки (вероятно, не совсем карликовой, раз нашла под него ресурсы и вообще заинтересована в данной технологии) - тебя, почему-то, совершенно не смущает?
На машине, где развернут гитлаб, довольно глупо иметь что-то, что надо героически защищать от гитлаба. Если ее через него поломают - целью, очевидно, будет именно гитлаб, и он же - основной твоей потерей.
Я, конечно, с интересом прочитал тут чей-то опус на тему "как его правильно кормить вручную, если хочется версию прямо из под комитеров", но прекрасно обойдусь в жизни без этого знания.Как и без ручного ковыряния с ключами и репо, которым занимается этот тривиальненький скриптик. А вот когда ты скажешь банальное apt-get install - запустится миллион нетривиальных, но "негореадмины" об этом даже не думают.
> А вот когда ты скажешь банальное apt-get install -
> запустится миллион нетривиальных, но "негореадмины" об этом даже не думают.Тут дело в доверии к репозиторию, т.к. «миллион» этих пакетов подписаны единым репозиторским ключом, а значит дистрибутив берёт под свою репутацию весь этот «миллион» пакетов. (На самом деле около 20т.)
> Тут дело в доверии к репозиториюда недоверяй, пажалуста. Ты пакеты-то с под него ставить собираешься, или где?
Если собираешься, кудыть ты денешься без ключа?
Не ставить пакетов - как будем вручную удовлетворять прожорливую зверушку, зависимую разом от ruby, go (а то одного ruby что-то мало показалось), nodejs (а то недостаточно хипстерски) и хз еще чего, плюс мильен модулей/библиотек/как оно там еще в них всех называется, причем все это существует в единственно-правильной версии без штатных возможностей отката и каких-либо представлений о совместимости, "живи сегодняшним днем" ?Ну и репо и даже его ключ можешь в принципе-то после установки хоть совсем выпилить - что толку, коли чудище огло, озорно, стозевно уже всю твою разработку пожрало и лайя?
Кто, где, чего и как в ем наскриптовал - проверить сил человеческих не хватит. Лучше уж оставить - оно хотя бы, может быть, апдейтиться будет.
Проблема что кто-то из их разработчиков вредный и завел себе теперь шелл на твоем сервере - ничто, по сравнению с тем, кто кто-то мог быть просто неаккуратный, и оно все сдохнет так, что и бэкап не поможет, за два дня до какого-нибудь глобального релиза.
Вот сам сервер, где это все крутится, действительно следует обматывать колючей проволокой в два ряда, снаружи и изнутри. А бояться запускать на нем что-либо, подсунутое разработчиками - поверь, пустое. Бояться надо было, когда выбирали это решение.
Но альтернатив такого размера, в общем, действительно, наверное, один платный гитхаб. Если хочется денег никому не платя, сохранить хотя бы видимость контроля за инфраструктурой (своего) проекта - наверное, и вариантов нет.
Почему не savannah?