Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
Со всех более-менее живых проектов на google code, уже давно стоят ссылки на github. Не думаю что кто-то заметит)
Не со всех.
С Vim никаких ссылок не стоит. Сейчас там жаркий спор GitHub vs BitBucket в vim-dev, некоторые даже предлагают SourceForge (!).
Боже мой, неужели кто-то в здравом уме ещё может предлагать Sourceforge? В последнее время с их страницы легче словить адварь чем скачать нужную программу.
Некоторые проекты на sourceforge до сих пор живы. У меня там несколько старых (все новые на BitBucket) проектов, tmux, PyPI (только issue tracker для поддержки пользователей (интересно, чем он им так понравился), сам сайт на BitBucket),
Но SF устарел и они с этим практически ничего не делают. Я бы ни за что не стал создавать там новый проект, если только мне опять не понадобятся удалённые bzr, mercurial, subversion и git репозитории одновременно для тестирования (и то, на SF будут репозитории для тестирования, а не сам проект).
eix --installed | grep -P 'Homepage:.*[./]sourceforge\.net' | wc -l выдаёт 131 пакет.Но SF устарел и они с этим практически ничего не делают. Я бы ни за что не стал создавать там новый проект, если только мне опять не понадобятся удалённые bzr, mercurial, subversion и git репозитории одновременно для тестирования (и то, на SF будут репозитории для тестирования, а не сам проект).
Кажется, ваш ник я видел не раз в коммитах neovim, так что теперь уже не пропадём :)
Я заметил. Мне как-то больше нравился гуглокод среди прочих.
Я просто счастлив! Наконец-то! :) Ничего личного, просто он был некрасивый, не удобный и я всегда огорчался, когда надо было с ним работать. Хотя у него был плюс: релизы и версии.
Э… а что, на гитхабе релизов нет? Для наших целей вполне хватает такого: github.com/0x7CFE/llst/releases
Какой еще функционал вы ожидаете от механизма релизов и версий?
Какой еще функционал вы ожидаете от механизма релизов и версий?
А я и не знал. Ну тогда совсем все хорошо :)
На гитхабе, к сожелению, нет никакой статистики по кол-ву скачиваний :( На данный момент больше всего статистики предоставляет Sourceforge и Codeplex, хотя все равно мало по сравнению с Google Analytics
количество скачиваний есть в json api… вот например: developer.github.com/v3/repos/releases/ искать «download_count»
Хуже всего то что чтобы с ним работать нужно иметь гугловский аккаунт, а значит подписать гугловскую EULA.
В отличии от гугль-ридера, этот проект и вправду был полумертв. Не могу спомнить, когда в последний раз что-ты выкачивал оттуда.
Гугол скатывается в полную задницу. Не удивлюсь, если они закроют gmail, а в хромоногую быдлоподелку воткнут толпу бэкдоров.
Да что вы говорите!
Из всех закрытых проектов жалко только ридера, остальные закрывать было необходимо. И ридер, возможно, тоже — сверху виднее. Это бизнес, и тратить деньги на непопулярные проекты никто в здравом уме не будет.
Из всех закрытых проектов жалко только ридера, остальные закрывать было необходимо. И ридер, возможно, тоже — сверху виднее. Это бизнес, и тратить деньги на непопулярные проекты никто в здравом уме не будет.
удалено, ошибся :) («вопросы и ответы» тоже не жалко)
Да всё жалко. Так же (для примера), как жалко сокращать сотрудников в связи с автоматизацией процессов, у них ведь ипотеки и дети, однако сами понимаете…
Вопросы и ответы в самом начале были похожи на тутошний Q&A, а в самом конце уже переплюнули toster и были похожи на otvety.mail. И вот самый первый в общем-то было жалко.
Поиск по коду жалко тоже. Google talks работал с джаббером и был добрым. Теперь стал злым.
Ты смотри, сколько, оказывается, на БХ рукожопых гуголопогромистов! Как минимум 41 штука!
99 разных проектов у Гугла, 99 сервисов разных.
Закрою один, все сбегут кто куда, 98 разных проектов у Гугла…
Закрою один, все сбегут кто куда, 98 разных проектов у Гугла…
Вот перевод письма, которое я получил (хотел сам оформить постингом, но меня опередили :).
Сервис Google Code закрывается.
Здравствуйте.
Чуть ранее сегодня мы сообщили о грядущем закрытии службы хостинга Google Code. Этот сервис был запущен в 2006-м году с целью предоставить надёжный и удобный хостинг для проектов с открытым исходным кодом. За прошедшее время миллионы людей внесли свой вклад в open-source проекты, размещённые в сервисе.
Однако с тех пор многое изменилось. За последние девять лет появилось множество других возможностей для размещения открытых проектов с поддержкой сообщества и разработчиков. Пришло время признать, что миссию Google Code в предоставлении хостинга для open source проектов ныне выполняют другие сайты, такие как GitHub и Bitbucket.
В последующие месяцы мы начинаем сворачивать и закрывать службу Google Code. Начиная с сегодняшнего дня мы отключаем возможность размещения новых проектов, однако все уже размещённые будут функционировать до августа 2015г. Затем данные станут доступными только для чтения. В начале следующего года сайт будет окончательно закрыт, однако сохранённые данные останутся доступными для загрузки в виде архивов.
У вас есть несколько вариантов для перемещения ваших данных.
Простейший способ — использовать Google Code Exporter, который позволит вам переместить ваши проекты прямо на Github. Также у нас имеются инструкции по ручной миграции на другие сервисы — Github, Bigbucket и SourceForge.
За дальнейшей информацией обращайтесь на Open Source blog или пишите по адресу google-code-shutdown@google.com.
— Команда Google Code.
Сервис Google Code закрывается.
Здравствуйте.
Чуть ранее сегодня мы сообщили о грядущем закрытии службы хостинга Google Code. Этот сервис был запущен в 2006-м году с целью предоставить надёжный и удобный хостинг для проектов с открытым исходным кодом. За прошедшее время миллионы людей внесли свой вклад в open-source проекты, размещённые в сервисе.
Однако с тех пор многое изменилось. За последние девять лет появилось множество других возможностей для размещения открытых проектов с поддержкой сообщества и разработчиков. Пришло время признать, что миссию Google Code в предоставлении хостинга для open source проектов ныне выполняют другие сайты, такие как GitHub и Bitbucket.
В последующие месяцы мы начинаем сворачивать и закрывать службу Google Code. Начиная с сегодняшнего дня мы отключаем возможность размещения новых проектов, однако все уже размещённые будут функционировать до августа 2015г. Затем данные станут доступными только для чтения. В начале следующего года сайт будет окончательно закрыт, однако сохранённые данные останутся доступными для загрузки в виде архивов.
У вас есть несколько вариантов для перемещения ваших данных.
Простейший способ — использовать Google Code Exporter, который позволит вам переместить ваши проекты прямо на Github. Также у нас имеются инструкции по ручной миграции на другие сервисы — Github, Bigbucket и SourceForge.
За дальнейшей информацией обращайтесь на Open Source blog или пишите по адресу google-code-shutdown@google.com.
— Команда Google Code.
Могли бы и подольше read-only доступ предоставлять — с них не убудет.
Наконец-то! А то, бывает, найдёшь программу или библиотеку, в которой чего-то не хватает, хочешь послать пулл-реквест, а выясняется, что оно на гугл-коде и там встроенной возможности для этого нет. И багтрекер там был странный, без права редактировать свои сообщения. Наверное, самое полезное, что там было — это возможность загружать файлы.
Она и на гитхабе есть, эта возможность. Т.н. «релизы».
Ну релизы это релизы, а в гуглокоде можно было любые файлы выкладывать, ЕМНИП.
На Гитхабе тоже можно выложить любые файлы, «привязав» их к тэгу.
Дополнительно к этому, есть замечательный BinTray, который интегрируется с GitHub и Maven Central (и не только).
Дополнительно к этому, есть замечательный BinTray, который интегрируется с GitHub и Maven Central (и не только).
На GitHub'е тоже можно выкладывать любые файлы. Их загрузка доступна при создании релиза.
Последний скриншот: github.com/blog/1547-release-your-software
Последний скриншот: github.com/blog/1547-release-your-software
Для хостинга программных проектов это скорее вредная возможность, имхо, так как быстро превращается в файлопомойку и непонятно, что к чему выложено и зачем. В 99% процентов случаев надо выкладывать именно собранные бинарники для конкретной версии — функциональность релизов отлично покрывает эту задачу.
Гугл в своем репертуаре. И на ридере, и на гугл-коде можно было зарабатывать — ведь зарабатывают и гитхаб, и битбакет. Но закрытие части бизнеса с, в общем-то, реальной моделью зарабатывания денег — это удел больших корпораций. Для них это не вопрос выживания, а всего-лишь актив. Плохо только, что сначала, прийдя на рынок с продуктом, за счет ресурсов выжигаются или выкупаются конкуренты, а в итоге остается обугленное поле.
Вывод, по сути один — не стоит боятся больших корпораций. То, что для кого-то успешный и выгодный бизнес, для них — невыгодный актив, от которого надо избавляться.
Вывод, по сути один — не стоит боятся больших корпораций. То, что для кого-то успешный и выгодный бизнес, для них — невыгодный актив, от которого надо избавляться.
Пусть еще SourceForge с собой заберут.
Я волнуюсь за мёртвые, но нужные проекты, например code.google.com/p/openvpn-auth-ldap/.
ненавижу git
От ненависти до любви один шаг:) Я тоже когда-то откровенно его ненавидел и сидел на SVN: а сейчас жизни не представляю без git.
Не скажу, что испытываю к системе контроля версий какие то чувства. Но единственный минус в git для меня, из-за которого я не использую его на проектах с малым количеством веток, это отсутствие externals. В случае же если в проекте требуется, хоть сколько нибудь существенное, ветвление кода и есть больше одной ветки, то git использовать становится гораздо приятнее чем svn. Ну а про различные бонусы git вроде оффлайн коммитов в репу, возможности адекватного слияния ревизий между собой и большей скорости работы я просто молчу, это очень удобно и это планомерная эволюция систем контроля версий.
Помимо этого использование TortoiseSVN и TortoiseGIT делают разницу в использовании разных репозиториев незаметной, ну а билд скрипты пишутся очень редко, а чаще и просто используются готовые с минимальными правками, так что синтаксис команд меня вообще не беспокоит.
P.S.… хотя вот CVS недолюбливаю, благо его везде уже успешно закопали.
Помимо этого использование TortoiseSVN и TortoiseGIT делают разницу в использовании разных репозиториев незаметной, ну а билд скрипты пишутся очень редко, а чаще и просто используются готовые с минимальными правками, так что синтаксис команд меня вообще не беспокоит.
P.S.… хотя вот CVS недолюбливаю, благо его везде уже успешно закопали.
Как было сказано в известном историческом анекдоте, «эта женщина уже на стольких людей производила впечатление, что она уже сама может выбирать, на кого ей производить впечатление, а на кого — нет».
Кроме убойной популярности (которая не на пустом месте возникла, согласитесь), у ГИТа есть несколько совершенно чудесных особенностей, делающих его незаменимым или просто удивительно удобным в ряде случаев.
Кроме убойной популярности (которая не на пустом месте возникла, согласитесь), у ГИТа есть несколько совершенно чудесных особенностей, делающих его незаменимым или просто удивительно удобным в ряде случаев.
Не понимаю, чему некоторые товарищи радуются.
Я понимаю, что гитхаб — это последний писк моды, но пропадет безвозвратно куча кода и бинарников.
Я понимаю, что гитхаб — это последний писк моды, но пропадет безвозвратно куча кода и бинарников.
Ну не все радуются, большинству безразлично.
На счет кода/бинарников: куда они пропадают? Ещё год будут в доступе. И если за этот год они вообще никому не понадобились (в том числе и авторам), то наверное туда им и дорога. Или я не прав?
На счет кода/бинарников: куда они пропадают? Ещё год будут в доступе. И если за этот год они вообще никому не понадобились (в том числе и авторам), то наверное туда им и дорога. Или я не прав?
Да, не прав.
Знаешь, как бывает? Возникла проблема, ищешь решение или кусок кода. И находишь его в каком-то старом коде.
Вот представь, что лет через пять тебе понадобится кусок кода, который есть только в одном месте — в Google Code.
Или найдётся смельчак, который скопирует весь код из Google Code в GitHub? Думаю, что нет.
Да и вообще, держать яйца в одной корзине, будь то GC или github, нельзя.
Знаешь, как бывает? Возникла проблема, ищешь решение или кусок кода. И находишь его в каком-то старом коде.
Вот представь, что лет через пять тебе понадобится кусок кода, который есть только в одном месте — в Google Code.
Или найдётся смельчак, который скопирует весь код из Google Code в GitHub? Думаю, что нет.
Да и вообще, держать яйца в одной корзине, будь то GC или github, нельзя.
> Вот представь, что лет через пять тебе понадобится кусок кода, который есть только в одном месте — в Google Code.
Нафантазировать можно что угодно.
> Или найдётся смельчак, который скопирует весь код из Google Code в GitHub? Думаю, что нет.
В новости написано что будет доступен архив — вот его растащат сердобольные люди и он будет доступен неограниченное время. В интернете вообще никогда ничего не исчезает.
Но, право, в реальном мире случаи когда гнивший в архиве пять лет код вдруг кому-то становился нужен для практического применения настолько редки что ни на долю процента не оправдывают существование GC.
> Да и вообще, держать яйца в одной корзине, будь то GC или github, нельзя.
GitHub — это не корзина с яйцами, а точка взаимодействия F/OSS сообщества, а оная должна быть ровно одна по очевидным чисто практическим причинам. Что до репозиториев, то в эпоху победившего DVCS переезд на новый хостинг или зеркалирование репозитория — дело пары команд. Поэтому сейчас не использовать GitHub — по меньшей мере непрактично.
Нафантазировать можно что угодно.
> Или найдётся смельчак, который скопирует весь код из Google Code в GitHub? Думаю, что нет.
В новости написано что будет доступен архив — вот его растащат сердобольные люди и он будет доступен неограниченное время. В интернете вообще никогда ничего не исчезает.
Но, право, в реальном мире случаи когда гнивший в архиве пять лет код вдруг кому-то становился нужен для практического применения настолько редки что ни на долю процента не оправдывают существование GC.
> Да и вообще, держать яйца в одной корзине, будь то GC или github, нельзя.
GitHub — это не корзина с яйцами, а точка взаимодействия F/OSS сообщества, а оная должна быть ровно одна по очевидным чисто практическим причинам. Что до репозиториев, то в эпоху победившего DVCS переезд на новый хостинг или зеркалирование репозитория — дело пары команд. Поэтому сейчас не использовать GitHub — по меньшей мере непрактично.
Что-то есть сомнение, что будет возможность поиска по архиву.
Так скачайте и ищите чем вам угодно.
Я с радостью, но вот архив технических ГОСТов весит минимум 20 ГБ, а объем моей личной папки с проектами за 8 лет работы уже перевалили за 30 ГБ и это только рабочие материалы — не архив, не репа. Какой объем необходим для хранения всех материалов для поиска мне представить пока не получается. Есть ли у кого такая аналитика? Можно скинутся на амазоновский S3 и туда все слить, а дальше думать что с этим делать. Но вот сколько скидываться даже не понятно
>а оная должна быть ровно одна
Хаха.
А теперь представь, что GitHub закрывается, как нынешний Google Code.
Хаха.
А теперь представь, что GitHub закрывается, как нынешний Google Code.
GitHub — это не корзина с яйцами, а точка взаимодействия F/OSS сообщества, а оная должна быть ровно одна по очевидным чисто практическим причинам. Что до репозиториев, то в эпоху победившего DVCS переезд на новый хостинг или зеркалирование репозитория — дело пары команд. Поэтому сейчас не использовать GitHub — по меньшей мере непрактично.Пары команд? Вы забываете про wiki и issue tracker. Если вторую и третью команду за вас ещё не написали, то просто так вы не отделаетесь. Плюс ещё нужно найти все места, где вы использовали старый URL и переделать его на новый.
А точка взаимодействия F/OSS сообщества ни в коем случае не должна быть ровно одна, потому что это порождает единую точку отказа. Если бы github был каким‐нибудь «распределённым» p2p сайтом, который никак не может закрыть один человек (здесь — владелец GH), то ещё можно было бы подумать. Защищённость сообщества от различных форс‐мажоров — это тоже чисто практическое соображение.
> Пары команд? Вы забываете про wiki и issue tracker. Если вторую и третью команду за вас ещё не написали, то просто так вы не отделаетесь. Плюс ещё нужно найти все места, где вы использовали старый URL и переделать его на новый.
wiki это такой же git репозиторий. С issue пока сложнее, но экспортировать их не проблема.
> А точка взаимодействия F/OSS сообщества ни в коем случае не должна быть ровно одна, потому что это порождает единую точку отказа.
Нет тут точки отказа. Точка взаимодействия по своей природе подразумевайт failover на следующий по популярности сервис в случае проблем с текущим. И да, она должна быть одна, потому что любое другое количество кратно уменьшает эффективность взаимодействия и увеличивает накладные расходы.
> Если бы github был каким‐нибудь «распределённым» p2p сайтом, который никак не может закрыть один человек (здесь — владелец GH), то ещё можно было бы подумать. Защищённость сообщества от различных форс‐мажоров — это тоже чисто практическое соображение.
Распределённое VCS хранилище это, конечно, замечательно, но повода использовать его нет и не будет, пока работает github.
wiki это такой же git репозиторий. С issue пока сложнее, но экспортировать их не проблема.
> А точка взаимодействия F/OSS сообщества ни в коем случае не должна быть ровно одна, потому что это порождает единую точку отказа.
Нет тут точки отказа. Точка взаимодействия по своей природе подразумевайт failover на следующий по популярности сервис в случае проблем с текущим. И да, она должна быть одна, потому что любое другое количество кратно уменьшает эффективность взаимодействия и увеличивает накладные расходы.
> Если бы github был каким‐нибудь «распределённым» p2p сайтом, который никак не может закрыть один человек (здесь — владелец GH), то ещё можно было бы подумать. Защищённость сообщества от различных форс‐мажоров — это тоже чисто практическое соображение.
Распределённое VCS хранилище это, конечно, замечательно, но повода использовать его нет и не будет, пока работает github.
wiki это такой же git репозиторий.… с файлами в определённом формате. Который на разных сайтах может различаться.
С issue пока сложнее, но экспортировать их не проблема.Только если есть скрипты для эскпорта и импорта. Иначе вам придётся их писать, при этом обязательно вылезет то, что разные сайты поддерживают разные возможности.
Нет тут точки отказа. Точка взаимодействия по своей природе подразумевайт failover на следующий по популярности сервис в случае проблем с текущим. И да, она должна быть одна, потому что любое другое количество кратно уменьшает эффективность взаимодействия и увеличивает накладные расходы.Корректный failover может быть невозможен по причине потери данных из‐за недоступности сайта. Чем бы вы не пользовались (даже если сайтов несколько) вам нужно периодически сохранять резервную копию issues и wiki, но если сайт используется один, то тут возникают проблемы, т.к. для непопулярных сайтов не написаны скрипты импорта.
Кстати, объясните‐ка мне, откуда появится «следующий по популярности сервис», если по вашему мнению точка взаимодействия одна? Т.е. по вашим словам получится, что либо их несколько (против чего вы протестуете), либо их не существует (⇒ failover невозможен).
Распределённое VCS хранилище это, конечно, замечательно, но повода использовать его нет и не будет, пока работает github.У вас — может быть. Другим нравится бо́льшая отказоустойчивость этой модели: тот же fossil (в одном репозитории сам код, wiki и issues) не просто так возник.
> … с файлами в определённом формате. Который на разных сайтах может различаться.
Даже если кто-то ещё не поддерживает markdown, разметка wiki — это в любом случае plaintext.
> Только если есть скрипты для эскпорта и импорта. Иначе вам придётся их писать, при этом обязательно вылезет то, что разные сайты поддерживают разные возможности.
При чём тут разные сайты? Одна миграция — один скрипт на всех.
> Корректный failover может быть невозможен по причине потери данных из‐за недоступности сайта. Чем бы вы не пользовались (даже если сайтов несколько) вам нужно периодически сохранять резервную копию issues и wiki, но если сайт используется один, то тут возникают проблемы, т.к. для непопулярных сайтов не написаны скрипты импорта.
Сохранять надо только issues, потому что wiki, повторюсь, обычный git репозиторий. При чём тут непопулярные сайты я не понял.
> Кстати, объясните‐ка мне, откуда появится «следующий по популярности сервис», если по вашему мнению точка взаимодействия одна?
Одна, потому что всё что хостится вне гитхаба выпадает из сообщества. Однако не все это понимают, поэтому другие хостинги ещё существуют.
> У вас — может быть. Другим нравится бо́льшая отказоустойчивость этой модели: тот же fossil (в одном репозитории сам код, wiki и issues) не просто так возник.
«Не просто так» им никто не пользуется.
Минусы github мне прекрасно известны, мне интересно что вы предлагаете в качестве альтернативы.
Даже если кто-то ещё не поддерживает markdown, разметка wiki — это в любом случае plaintext.
> Только если есть скрипты для эскпорта и импорта. Иначе вам придётся их писать, при этом обязательно вылезет то, что разные сайты поддерживают разные возможности.
При чём тут разные сайты? Одна миграция — один скрипт на всех.
> Корректный failover может быть невозможен по причине потери данных из‐за недоступности сайта. Чем бы вы не пользовались (даже если сайтов несколько) вам нужно периодически сохранять резервную копию issues и wiki, но если сайт используется один, то тут возникают проблемы, т.к. для непопулярных сайтов не написаны скрипты импорта.
Сохранять надо только issues, потому что wiki, повторюсь, обычный git репозиторий. При чём тут непопулярные сайты я не понял.
> Кстати, объясните‐ка мне, откуда появится «следующий по популярности сервис», если по вашему мнению точка взаимодействия одна?
Одна, потому что всё что хостится вне гитхаба выпадает из сообщества. Однако не все это понимают, поэтому другие хостинги ещё существуют.
> У вас — может быть. Другим нравится бо́льшая отказоустойчивость этой модели: тот же fossil (в одном репозитории сам код, wiki и issues) не просто так возник.
«Не просто так» им никто не пользуется.
Минусы github мне прекрасно известны, мне интересно что вы предлагаете в качестве альтернативы.
Даже если кто-то ещё не поддерживает markdown, разметка wiki — это в любом случае plaintext.Во‐первых, markdown — далеко не лучший формат для wiki. Я никогда не выбрал бы его по своей воле, если сайт поддерживает ещё что‐то.
Во‐вторых, всякий файл в wiki — это в любом случае набор байт. Значит, я могу загрузить туда docx. Никого не волнует, plaintext там или нет, если браузер в результате ничего не покажет или покажет какой‐то ужас.
При чём тут разные сайты? Одна миграция — один скрипт на всех.Что?! У каждого сайта свои механизмы экспорта и импорта. Вы можете запихать их в один скрипт, но это будет то же самое, что и собранные с USE=multicall coreutils (для тех, кто не в курсе: USE=multicall запихивает все команды coreutils (cp, mv, seq, chown, test, sha512sum, …) в один большой бинарник). Т.е. набор связанных общей идеей совершенно разных скриптов.
Сохранять надо только issues, потому что wiki, повторюсь, обычный git репозиторий.«Обычный репозиторий», разумеется, появляется на машине разработчика неким магическим образом.
Если вы не забыли, wiki можно редактировать из браузера. Многие так и делают.
При чём тут непопулярные сайты я не понял.Потому что для них нет скриптов импорта. Или конвертации wiki в местный формат. Или конвертации issues в формат, который можно импортировать.
Одна, потому что всё что хостится вне гитхаба выпадает из сообщества. Однако не все это понимают, поэтому другие хостинги ещё существуют.Я спрашивал, «откуда появится „следующий по популярности сервис“». Я не спрашивал, «почему точка взаимодействия одна». Особенно, если «другие хостинги существуют» всего лишь «ещё».
Если сообщества F/OSS программистов на сайте нет, то на его нужды всем насрать. Вы сами своими руками делаете так, что с github будет нельзя куда‐либо переехать, даже если альтернативы и будут, т.к. это будут альтернативы только для тех, кто собирается платить. Если бы такими были все F/OSS разработчики, то альтернатив бы не было сейчас.
«Не просто так» им никто не пользуется.Им пользуются. Просто очень мало людей, по сравнению с теми же github и bitbucket.
Минусы github мне прекрасно известны, мне интересно что вы предлагаете в качестве альтернативы.Я ничего не предлагаю в качестве «альтернативы». Просто не игнорируйте другие сайты.
> Я ничего не предлагаю в качестве «альтернативы».
Тогда о чём вообще разговор?
> Просто не игнорируйте другие сайты.
В чём должно выражаться «не игнорирование»?
Тогда о чём вообще разговор?
> Просто не игнорируйте другие сайты.
В чём должно выражаться «не игнорирование»?
Тогда о чём вообще разговор?Вы пытаетесь убедить остальных, что GitHub должен быть единственным сайтом, на котором происходит F/OSS разработка. Я говорю, что он должен быть не единственным таким сайтом. «Альтернативу GitHub» я бы предлагал, если бы говорил, что, к примеру, BitBucket должен быть также единственным сайтом.
В чём должно выражаться «не игнорирование»?Судя по вашему профилю на BitBucket, проекты, находящиеся там вы всё‐таки не игнорируете (в комментариях вы предлагали всем использовать GitHub, т.к. обратное непрактично, так что это было более, чем вероятно). Так что просто не агитируйте остальных за отказ от сайтов, отличных от GitHub.
Кстати, вы так и не ответили на вопрос о том, откуда должны взяться альтернативы GitHub, если их никто не будет использовать по причине непрактичности.
> Вы пытаетесь убедить остальных, что GitHub должен быть единственным сайтом, на котором происходит F/OSS разработка.
Я говорю о том что GitHub обладает наибольшей аудиторией и игнорировать это крайне глупо — на любом другом хостинге ваш проект будет отдалён, если не отрезан от этой аудитории, а в открытой разработке доступность — один из самых критичных факторов. При этом все риски гитхаба будут актуальны и на любом другом существующем хостинге.
> Я говорю, что он должен быть не единственным таким сайтом.
То есть всё-таки предлагаете. Тогда раскрывайте мысль: сколько должно быть сайтов, по каким критериям нужно определять на каком сайте хостить проект, хостить ли на одном или сразу на нескольких, и т.д. Если на одном, то чем не-github будет лучше github, а если на нескольких, собираетесь ли вы зеркалировать issues и wiki (при всех проблемах с этим, которые сами же перечислили) или нет (значит с возможностью потери данных плюс с необходимостью разбираться с дубликатами).
> Судя по вашему профилю на BitBucket, проекты, находящиеся там вы всё‐таки не игнорируете
То есть количество репозиториев и дата вам ничего не говорит? На вопрос вы не ответили.
> Кстати, вы так и не ответили на вопрос о том, откуда должны взяться альтернативы GitHub, если их никто не будет использовать по причине непрактичности.
Вопрос некорректен ибо содержит ложные предпосылки. Альтернативам не надо браться — они есть сейчас. Не нужные в данный момент по причине более низкой популярности, но, в принципе, готовые занять место гитхаба случись что с ним.
Я говорю о том что GitHub обладает наибольшей аудиторией и игнорировать это крайне глупо — на любом другом хостинге ваш проект будет отдалён, если не отрезан от этой аудитории, а в открытой разработке доступность — один из самых критичных факторов. При этом все риски гитхаба будут актуальны и на любом другом существующем хостинге.
> Я говорю, что он должен быть не единственным таким сайтом.
То есть всё-таки предлагаете. Тогда раскрывайте мысль: сколько должно быть сайтов, по каким критериям нужно определять на каком сайте хостить проект, хостить ли на одном или сразу на нескольких, и т.д. Если на одном, то чем не-github будет лучше github, а если на нескольких, собираетесь ли вы зеркалировать issues и wiki (при всех проблемах с этим, которые сами же перечислили) или нет (значит с возможностью потери данных плюс с необходимостью разбираться с дубликатами).
> Судя по вашему профилю на BitBucket, проекты, находящиеся там вы всё‐таки не игнорируете
То есть количество репозиториев и дата вам ничего не говорит? На вопрос вы не ответили.
> Кстати, вы так и не ответили на вопрос о том, откуда должны взяться альтернативы GitHub, если их никто не будет использовать по причине непрактичности.
Вопрос некорректен ибо содержит ложные предпосылки. Альтернативам не надо браться — они есть сейчас. Не нужные в данный момент по причине более низкой популярности, но, в принципе, готовые занять место гитхаба случись что с ним.
Я говорю о том что GitHub обладает наибольшей аудиторией и игнорировать это крайне глупо — на любом другом хостинге ваш проект будет отдалён, если не отрезан от этой аудитории, а в открытой разработке доступность — один из самых критичных факторов. При этом все риски гитхаба будут актуальны и на любом другом существующем хостинге.Для одного проекта они будут актуальны. Для сообщества они уменьшаются в соответствие с количеством используемых сайтов и долей проектов на них.
То есть всё-таки предлагаете. Тогда раскрывайте мысль: сколько должно быть сайтов, по каким критериям нужно определять на каком сайте хостить проект, хостить ли на одном или сразу на нескольких, и т.д. Если на одном, то чем не-github будет лучше github, а если на нескольких, собираетесь ли вы зеркалировать issues и wiki (при всех проблемах с этим, которые сами же перечислили) или нет (значит с возможностью потери данных плюс с необходимостью разбираться с дубликатами).Просто исключите «размер местного сообщества» из критериев выбора и действуйте соответственно другим критериям. Идеальным является результат, при котором проекты равномерно распределены по сайтам в соответствие с их качеством и надёжностью: наличием требуемых возможностей (т.е. SF не имеет интеграции с travis или альтернативами — ну его нафиг, если в проекте есть тесты, которые можно там запустить), downtime, известными случаями удаления репозиториев, известными уязвимостями и скоростью их исправления.
Отсутствие или необходимость зеркалирования определяется из желаемого уровня отказоустойчивости.
Суть в том, чтобы сообщество не потеряло слишком много проектов с потерей одного сайта, а не в том, чтобы вы не потеряли свой проект с потерей GitHub — для последнего есть резервное копирование. В случае более равномерного распределения всё равно обязательно напишут скрипты импорта/экспорта: для зеркалирования, переезда в соответствие с новыми возможностями, … Они и сейчас есть, только более однобокие: GH→BB мне в своё время пришлось писать самому, т.к. те варианты, которые я нашёл, не поддерживали все возможности, которые можно было поддержать.
То есть количество репозиториев и дата вам ничего не говорит?Проектов на BitBucket мало. У меня там мои репозитории, но я не могу вспомнить, когда последний раз делал что‐то (описывал ошибки, создавал PR, …) с другими. Я вижу, что у вас были 2 PR и одна issue там. У меня должно быть немногим больше, если не считать свои репозитории.
При этом у меня на GitHub своих репозиториев нет.
На вопрос вы не ответили.По‐моему, он и так понятен: «не игнорировать» — не отказываться сообщать об ошибках или создавать PR, если проект находится на другом сайте.
Вопрос некорректен ибо содержит ложные предпосылки. Альтернативам не надо браться — они есть сейчас. Не нужные в данный момент по причине более низкой популярности, но, в принципе, готовые занять место гитхаба случись что с ним.Вопрос корректен. В соответствие с вашими представлениями идеальным является состояние, когда все участники F/OSS сообщества разрабатывают свои проекты на GitHub вплоть до его закрытия. Откуда должны взяться альтернативы в идеальном случае? Я не спрашивал про текущую ситуацию.
> Для одного проекта они будут актуальны. Для сообщества они уменьшаются в соответствие с количеством используемых сайтов и долей проектов на них.
Предпосылки и вытекающие из них рассуждения неверны. Потерять половину репозиториев ничем не лучше чем все. Свободные проекты это не песок который остаётся песком если отсыпать половину, а набор уникальных сущностей, проблема у значительной части которых — проблема всех. При этом чем больше хостингов, тем больше вероятность потери одного из них. Вы, грубо говоря, предлагаете RAID0 для увеличения надёжности. Кроме того, проекты с почившего хостинга в любом случае переезжают на самый популярный, т.е. в перспективе получаем, опять таки, один GitHub. Каждый отдельный репозиторий или пользователь не выигрывает ничего, но теряет аудиторию и удобство взаимодействия, сообщество теряет целостность, а эти факторы куда важнее, чем гипотетический переезд раз в десятилетие.
При этом всём, компрометация github как единственного хостинга будет означать неизбежность перехода на полноценную децентрализацию (одной из попыток такое сделать был gitchain) и такие проекты наконец начнут развиваться. Этот момент тоже не имеет смысла оттягивать.
> Откуда должны взяться альтернативы в идеальном случае? Я не спрашивал про текущую ситуацию.
Не вижу смысла отвечать на чисто гипотетический вопрос.
Предпосылки и вытекающие из них рассуждения неверны. Потерять половину репозиториев ничем не лучше чем все. Свободные проекты это не песок который остаётся песком если отсыпать половину, а набор уникальных сущностей, проблема у значительной части которых — проблема всех. При этом чем больше хостингов, тем больше вероятность потери одного из них. Вы, грубо говоря, предлагаете RAID0 для увеличения надёжности. Кроме того, проекты с почившего хостинга в любом случае переезжают на самый популярный, т.е. в перспективе получаем, опять таки, один GitHub. Каждый отдельный репозиторий или пользователь не выигрывает ничего, но теряет аудиторию и удобство взаимодействия, сообщество теряет целостность, а эти факторы куда важнее, чем гипотетический переезд раз в десятилетие.
При этом всём, компрометация github как единственного хостинга будет означать неизбежность перехода на полноценную децентрализацию (одной из попыток такое сделать был gitchain) и такие проекты наконец начнут развиваться. Этот момент тоже не имеет смысла оттягивать.
> Откуда должны взяться альтернативы в идеальном случае? Я не спрашивал про текущую ситуацию.
Не вижу смысла отвечать на чисто гипотетический вопрос.
Предпосылки и вытекающие из них рассуждения неверны. Потерять половину репозиториев ничем не лучше чем все. Свободные проекты это не песок который остаётся песком если отсыпать половину, а набор уникальных сущностей, проблема у значительной части которых — проблема всех. При этом чем больше хостингов, тем больше вероятность потери одного из них. Вы, грубо говоря, предлагаете RAID0 для увеличения надёжности. Кроме того, проекты с почившего хостинга в любом случае переезжают на самый популярный, т.е. в перспективе получаем, опять таки, один GitHub. Каждый отдельный репозиторий или пользователь не выигрывает ничего, но теряет аудиторию и удобство взаимодействия, сообщество теряет целостность, а эти факторы куда важнее, чем гипотетический переезд раз в десятилетие.В перспективе не будет одного GitHub, т.к. будут появляться новые сайты. Наличие множества одинаково используемых сайтов означает высокую вероятность наличия скриптов миграции между ними (а если они будут открываться/закрываться, то это фактически гарантировано). И это не RAID0, а БД в режиме горизонтального шардинга, без репликации. Если что‐то грохнулось, то это очень неприятно и нам придётся восстанавливать из резервной копии это что‐то, но при одинаковой вероятности закрытия каждого хостинга лучше восстанавливать 2 000 проектов из 10 000 за один раз, чем 10 000 сразу.
Кроме того, именно у меня есть и другой интерес: мне mercurial нравится больше, чем git, а его на GitHub нет.
При этом всём, компрометация github как единственного хостинга будет означать неизбежность перехода на полноценную децентрализацию (одной из попыток такое сделать был gitchain) и такие проекты наконец начнут развиваться. Этот момент тоже не имеет смысла оттягивать.Мой вариант как раз оттягивает этот момент. Но хотя децентрализованный сайт и лучше, я не буду поддерживать такую инициативу раньше, чем в ней будет поддержка mercurial.
А я вот могу предложить альтернативу. Есть такой прекрасный открытый движок: about.gitlab.com
Думаю, если он станет стандартом де-факто в мире git и на нем откроется ряд сайтов-репозитариев, доля GitHub значительно потеснится.
Думаю, если он станет стандартом де-факто в мире git и на нем откроется ряд сайтов-репозитариев, доля GitHub значительно потеснится.
Не станет, как не стал за 7 лет gitorious. Собственные установки таких движков имеют смысл при закрытой разработке в больших командах. Для открытой разработки это ненужные накладные расходы на поддержку инфраструктуры и, главное, отрыв от сообщества.
Я щупал и gitorious, и github. Первый по функционалу и красоте значительно уступает GitHub. Второй — ощутимо превосходит по ряду признаков. Думаю, у него больше шансов создать конкуренцию, учитывая цены на корпоративные тарифы.
Мы обсуждаем хостинг свободных проектов, при чём здесь корпоративные тарифы?
При том, что хостинг свободных проектов должен на чем-то зарабатывать. Вот GitHub, например, очень недешево продает свой движок для корпоративных клиентов
А если платформа желает стать стандартом для движка СКВ git в интернете, ей необходимо понравиться всем — и «нищебродам», и «толстосумам». Иначе у нее действительно ничего не получится. Это, на мой взгляд, работает так: на работе программерам развернули движок, они к нему привыкли, он им нравится, дома они начинают искать хостинг на этом движке или разворачивать его самостоятельно, для себя, в результате в сети появляется открытый сервис на этом движке. Всё, ком покатился — все перешли на новую платформу.
Сравните цену за GitLab с поддержкой с приведенным выше тарифом. Пятьдесят баксов в год! Всего пятьдесят баксов. Это мы с вами, скинувшись напополам, могли бы приобрести на двоих. Как вам разница в сто раз? Не аргумент, чтобы смотреть с оптимизмом?
Pricing for GitHub Enterprise starts at $5,000 per 20-user seat pack per year...
А если платформа желает стать стандартом для движка СКВ git в интернете, ей необходимо понравиться всем — и «нищебродам», и «толстосумам». Иначе у нее действительно ничего не получится. Это, на мой взгляд, работает так: на работе программерам развернули движок, они к нему привыкли, он им нравится, дома они начинают искать хостинг на этом движке или разворачивать его самостоятельно, для себя, в результате в сети появляется открытый сервис на этом движке. Всё, ком покатился — все перешли на новую платформу.
Сравните цену за GitLab с поддержкой с приведенным выше тарифом. Пятьдесят баксов в год! Всего пятьдесят баксов. Это мы с вами, скинувшись напополам, могли бы приобрести на двоих. Как вам разница в сто раз? Не аргумент, чтобы смотреть с оптимизмом?
> А если платформа желает стать стандартом для движка СКВ git в интернете, ей необходимо понравиться всем — и «нищебродам», и «толстосумам»
Нет. Не надо мешать инструменты использующиеся в корпоративной среде и в разработке свободных проектов — это совершенно разные классы и требования, часто несовместимые. Эти миры пересекаются очень слабо, а если и пересекаются то скорее в другую сторону — «на работах» ставят то к чему привыкли работники.
> на работе программерам развернули движок, они к нему привыкли, он им нравится, дома они начинают искать хостинг на этом движке или разворачивать его самостоятельно, для себя, в результате в сети появляется открытый сервис на этом движке.
Причины по которым разворачивать движок не имеет смысла я уже озвучил, а очередной бесплатный глобальный хостинг должен чем-то привлечь пользователей, для которых GitHub уже стандарт.
> Сравните цену за GitLab с поддержкой с приведенным выше тарифом. Пятьдесят баксов в год! Всего пятьдесят баксов. Это мы с вами, скинувшись напополам, могли бы приобрести на двоих. Как вам разница в сто раз? Не аргумент, чтобы смотреть с оптимизмом?
Ещё раз, основной массе свободных проектов это и бесплатно не нужно. Конкуренция на корпоративном рынке и её последствия для GH как хостинга — это отдельная тема, которую я обсуждать не вижу смысла. И причин для оптимизма тут нет, поскольку если конкуренция на корпоративном рынке отрицательно скажется на состоянии GH, то пострадает сообщество.
Нет. Не надо мешать инструменты использующиеся в корпоративной среде и в разработке свободных проектов — это совершенно разные классы и требования, часто несовместимые. Эти миры пересекаются очень слабо, а если и пересекаются то скорее в другую сторону — «на работах» ставят то к чему привыкли работники.
> на работе программерам развернули движок, они к нему привыкли, он им нравится, дома они начинают искать хостинг на этом движке или разворачивать его самостоятельно, для себя, в результате в сети появляется открытый сервис на этом движке.
Причины по которым разворачивать движок не имеет смысла я уже озвучил, а очередной бесплатный глобальный хостинг должен чем-то привлечь пользователей, для которых GitHub уже стандарт.
> Сравните цену за GitLab с поддержкой с приведенным выше тарифом. Пятьдесят баксов в год! Всего пятьдесят баксов. Это мы с вами, скинувшись напополам, могли бы приобрести на двоих. Как вам разница в сто раз? Не аргумент, чтобы смотреть с оптимизмом?
Ещё раз, основной массе свободных проектов это и бесплатно не нужно. Конкуренция на корпоративном рынке и её последствия для GH как хостинга — это отдельная тема, которую я обсуждать не вижу смысла. И причин для оптимизма тут нет, поскольку если конкуренция на корпоративном рынке отрицательно скажется на состоянии GH, то пострадает сообщество.
Давайте перечислим, что входит в GitHub и GitLab:
1. Собственно, git с просмотром коммитов, веток, тэгов и релизов
2. Issues (или что-то типа багтрекера) с возможностью добавлять файлы (привет, GitHub ;)
3. Пользователи, настройки, минимальные социальные возможности, code snippets и прочие подобные плюшки
4. Интеграция с CI-сборочными системами
Если вы мне скажете, что из перечисленного не нужно корпоративным клиентам и/или частным indie/open-source разработчикам, я готов согласиться, что одна и та же система неспособна обслужить всех. Что же касается заявления
я могу сказать следующее: мой рабочий опыт включает в себя три крупные компании, две из которых — транснациональные. Ни в одной и них мне, увы, не приходилось иметь дело с популярными инструментами — как правило это были чисто коммерческие и совершенно неудобные инструменты. Ни меня, ни моих технических руководителей, насколько я знаю, ни разу никто не спросил о том, какие системы разворачивать, помимо одного случая, когда мы с напарником «взбунтовались» и потребовали установить нам на сервер git. Но и в том случае нас не спрашивали, какой именно сервер разворачивать.
Надеюсь, что мне просто не повезло и у вас более удачный опыт.
1. Собственно, git с просмотром коммитов, веток, тэгов и релизов
2. Issues (или что-то типа багтрекера) с возможностью добавлять файлы (привет, GitHub ;)
3. Пользователи, настройки, минимальные социальные возможности, code snippets и прочие подобные плюшки
4. Интеграция с CI-сборочными системами
Если вы мне скажете, что из перечисленного не нужно корпоративным клиентам и/или частным indie/open-source разработчикам, я готов согласиться, что одна и та же система неспособна обслужить всех. Что же касается заявления
«на работах» ставят то к чему привыкли работники,
я могу сказать следующее: мой рабочий опыт включает в себя три крупные компании, две из которых — транснациональные. Ни в одной и них мне, увы, не приходилось иметь дело с популярными инструментами — как правило это были чисто коммерческие и совершенно неудобные инструменты. Ни меня, ни моих технических руководителей, насколько я знаю, ни разу никто не спросил о том, какие системы разворачивать, помимо одного случая, когда мы с напарником «взбунтовались» и потребовали установить нам на сервер git. Но и в том случае нас не спрашивали, какой именно сервер разворачивать.
Надеюсь, что мне просто не повезло и у вас более удачный опыт.
Скорее всего таких смельчаков довольно много, вопрос только в создание единого реестра всех проектов. Есть такой список?
Лично мне не нравиться переезд на github.
У меня пакеты в java-коде называются com.googlecode.имя проекта
У меня пакеты в java-коде называются com.googlecode.имя проекта
Ничто не мешает называться им так и дальше. Ну а я поступил надёжней— купил себе собственный домен. Его именем и назывались пакеты, когда я пытался что-то делать на java.
Сейчас при попытке экспорта пишет
«The Google Code Exporter is experiencing extremely high traffic. The export queue is full. Please come back later. „
«The Google Code Exporter is experiencing extremely high traffic. The export queue is full. Please come back later. „
Google Code закрывают и предлагают перехать на GitHub. А если GitHub прикроют… И гугль и гитхаб американские компании. Вот если бы проекты перевести куда-нибудь на Яндекс или Mail.Ru кабы они такие сервисы имели.
Про прикрывание github я написал выше, а по поводу отечественных хостингов — боже упаси. Это сразу означает ограничить аудиторию пользователей и участников проекта русскоговорящими, а также риск потерять репозиторий в любой момент — законов у нас для этого принято достаточно. Не хочу даже предполагать как такой проект будет реализован.
GitHub для меня слишком гибкий сервис.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google Code закрывается и предлагает всем перейти на GitHub