LINUX.ORG.RU

Хостинг git-репозитория Linux временно переехал на GitHub

 , , ,


0

1

Линус Торвальдс (Linus Torvalds), LKML, воскресение, 4 Сентября 2011 16:27:25 UTC-7:

Прошла ещё одна неделя, и пришло время для ещё одного релиз-кандидата. Однако, master.kernel.org всё ещё не работает, и так как разработка не очень ведётся, то я решил пропустить эту неделю.

Но блин, вся суть (ну или почти вся) распределённой разработки заключается в том, что никакое место принципиально не отличается от любого другого, и так как я уже создал аккаунт на github ради divelog, почему бы не проверить, подойдёт ли оно мне, выложив туда весь мой репозиторий ядра?

Так что пока kernel.org отключён на аудит, давайте посмотрим, как будет пахать github:

https://github.com/torvalds/linux

ЗАМЕЧАНИЕ! Первое, что надо сделать, когда видите подобное заявление о любом новом публичном хостинге, это проверить, что да, его делает тот человек, о котором вы и думаете. Ну и как это сделать?

Можете выбрать любые пункты из списка:

  1. Чёрт, это ж открытый код, какая разница, кто это выложил, я просто хочу новое ядро, и хотя нет обновлений с kernel.org, мне действительно нужно исправление из нового ядра. Я скачаю его, потому что мне надо тренировать мой процессор в сборке ядра с randconfig. А ещё мне нравится жить в опасности.
  2. Да, письмо явно выглядит как от Линуса Торвальдса, и все знают, что SMTP не обманешь, так что это должен быть он.
  3. Итак, я могу вытащить дерево исходников, и знаю, что у Линуса всегда тэги подписаны, и могу проверить, что тэг 3.1-rc5 подписан его известным публичным ключом GPG, который я где-то достал. Если всё сойдётся, то для меня неважно, кто анонсировал релиз, я просто верю, что дерево подписал Линус.
  4. Я просто подожду, пока kernel.org прочухается.

Что вам больше подходит.

Ещё одно замечание — если вы просто сделаете

git pull https://github.com/torvalds/linux.git
то тэги вы не получите, так как это не ваша ветка. Сделайте также:
git fetch --tags <...>
что бы получить не только изменения в дереве, но и тэги.

Проект на github

>>> Подробности

★★★★

Проверено: maxcom ()
Последнее исправление: adriano32 (всего исправлений: 4)

Ответ на: комментарий от alx_me

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

yoghurt ★★★★★
()
Ответ на: комментарий от tazhate

Это по первости. А затем клиенты с платных аккаунтов разбегутся на менее загруженные площадки и останется только этот самый известный орган, который накроет весь сервис.

AVL2 ★★★★★
()

Я просто подожду, пока kernel.org прочухается.

Прочухался уже

real_kas
()
Ответ на: комментарий от alx_me

> «децентрализация» в контексте vcs

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

Ну если грубо это портаж-файл ;) А дисты у всего народа локально.

mx__ ★★★★★
()
Ответ на: комментарий от AVL2

на менее загруженные площадки

ога, с лагучего жж и вк много народу ушло, да :)

tazhate ★★★★★
()
Ответ на: комментарий от mx__

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

alx_me ★★☆
()
Ответ на: комментарий от mx__

>Да правильно я все понимаю. Проект один.

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

AVL2 ★★★★★
()
Ответ на: комментарий от alx_me

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

С P2P push-ем да, тоже «весело».

Но и говорить об отсутствии проблем с «временными» файлами, ИМХО, все же нельзя. С незакоммиченными изменениями все ясно, но в DVCS, в отличие от централизованных «собратьев» вроде той же SVN, наличие коммита ничего не значит — будь у тебя хоть тыща коммитов, до пуша о них никто даже не узнает и ты можешь делать с ними все, что захочешь. И вот тут-то у «Ъ-децентрализации» начинаются приключения — нужно каким-то волшебным образом определить, какие коммиты можно забирать, а какие нет. Полагаться на других участников нельзя, т.к. в общем случае возможна ситуация, когда во время push-а никого в сети не окажется и сообщать об изменениях будет просто некому (как раз тут еще и описанная упомянутая тобой проблема синхронизации и прочих аспектов push-а). Причем, даже если хранить на сервере только метаданные, «шапку», то, опять же, в общем случае может оказаться так, что во время появления в сети других участников проекта в онлайне не будет уже тебя — сервер им говорит «у Васи есть новые коммиты», но взять их они не могут (пока-единственный обладатель коммитов в оффлайне), снова проблема синхронизации.

В общем, есть большие сомнения в принципиальной возможности создания нормальной «Ъ- децентрализованной» VCS.

anonymous
()
Ответ на: комментарий от anonymous

Да нет тут никаких проблем.

Есть цифровые подписи коммитов, есть пиры, на которые можно гнать коммиты, есть бранчи, которые тоже подписаны и так же идут через пиры. Есть черные и белые списки коммитеров. Есть поиск бранчей по пирам. Все, больше ничего не надо. Достаточно иметь ключ линуса, найти его бранчи и сделать пулл нужного бранча.

Нет только необходимости в оном.

AVL2 ★★★★★
()
Ответ на: комментарий от slovazap

>> Авторитетно заявляю, и mercurial и darcs пользуются не только фанаты языков на которых они написаны. Прецеденты есть.

Отдельных прецедентов не достаточно чтобы опровергнуть правило. А то по всем выживжим в несчастных случаях можно сказать что в несчастных случаях не умирают.

Прецедентов достаточно чтобы опровергнуть правило. По всем выжившим в несчастных случаях можно сказать что в несчастных случаях люди умирают не всегда.

Прекратите разводить демагогию.

naryl ★★★★★
()
Ответ на: комментарий от slovazap

> fof (начал ненавидеть питон именно когда поиграл во frets on fire - игра замечательная, но падает и тормозит просто до невозможности, и в коде разобраться малореально).

Вот здесь одобряю полностью. Хотя, по вашей логике, отдельный прецедент (fof) ещё не говорит что питон - говно.

naryl ★★★★★
()
Ответ на: комментарий от naryl

Фанатики есть везде. И даркс и ртуть написаны для тех, для кого определяющим является язык разработки.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

> Фанатики есть везде. И даркс и ртуть написаны для тех, для кого определяющим является язык разработки.

Во, золотые слова.

slovazap ★★★★★
()
Ответ на: комментарий от AVL2

> Фанатики есть везде. И даркс и ртуть написаны для тех, для кого определяющим является язык разработки

О, а вот и фанатик. Или фанатики пайтона автоматически фанатаеют по Си?

anonymous
()
Ответ на: комментарий от anonymous

> Но и говорить об отсутствии проблем с «временными» файлами, ИМХО, все же нельзя....

Вы усложняете. Ну введут новую команды git exportp2p. С этого момента N commit-ов становятся доступными для p2p.

Ъ VCS это вообще не известно что. Сначала понять бы неплохо чем не устраивает git. По мне так он очень неплох. Добавить ещё один транспорт доставки diff-ов не является не реальным. И не важно p2p он или нет. Появится gitp2pd + git config p2p_download.enable true и все дела.

alx_me ★★☆
()
Ответ на: комментарий от alx_me

> Сначала понять бы неплохо чем не устраивает git.

Как раз меня-то он тоже вполне устраивает и «Ъ-VCS» я не ищу. Да и есть сомнения, что P2P тут вообще нужен — в большинстве случаев объемы скачиваемых данных не настолько велики («git clone» не в счет), чтобы можно было получить существенный профит, зато определенный гемморой с реализацией механизма «полной децентрализации» гарантирован.

anonymous
()
Ответ на: комментарий от AVL2

> И даркс и ртуть написаны для тех, для кого определяющим является язык разработки.

Откуда взялось это мнение?

naryl ★★★★★
()
Ответ на: комментарий от AVL2

Например, почему вы не говорите что git написан для тех, для кого определяющим является язык разработки - фанатиков C+bash?

naryl ★★★★★
()
Ответ на: комментарий от naryl

>для кого определяющим является язык разработки - фанатиков C+bash?

А те разве не mercurial юзают, как самый простой и надежный.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

> А те разве не mercurial юзают, как самый простой и надежный.

Вы что, с ума сошли?(с)

Самый простой и надёжный это git. Недоvcs чур не рассматривать. Среди оставшихся самый надёжный и простой это git.

alx_me ★★☆
()
Ответ на: комментарий от naryl

>Например, почему вы не говорите что git написан для тех, для кого определяющим является язык разработки - фанатиков C+bash?

потому что таких не существует.

Це нравится только тем, кто использует программы, а не пишет их. Это язык приятного результата, а не оргастического процесса разработки.

Баш вообще ни для чего, кроме мелких скриптиков не пригоден. Шореволл слава те БГ, переписали на перле и теперь программ на нем совсем не осталось.

AVL2 ★★★★★
()
Ответ на: комментарий от alx_me

>Самый простой и надёжный это git

Комбайнеры детектед.

devl547 ★★★★★
()

> пока kernel.org отключён на аудит

А что мешает повесить хотя бы простенькую HTML-страничку на старом адресе с объяснением причины и ссылкой на github, чтобы новый адрес не приходилось выискивать? Для этого подошел бы самый паршивый сервер с на скору руку установленным lighttpd

YAR ★★★★★
()

WTF: где теперь взять патч, скажем для 2.6.36->2.6.37?

Народ, а как вы теперь патчи с гитхаба получаете? Скажем не хочу я git clone делать, у меня уже есть полные src 2.6.36. Хочу только пропатчить их например до 2.6.37, не выкачивая при этом полного 2.6.37. Можно это как-то сделать или нет?

dad1979
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.