Gitea: Гитея приняла Гитею

Очень хорошая идея!

1,2 в феврале, 1,3 в апреле, 1,4 в июне, 1,5 в августе? должно быть достаточно времени, чтобы реализовать все это 😄

Если вы еще не видели, фантастический и проницательный комментарий, поддерживающий ваш подход к самостоятельному размещению, только когда он будет готов: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@lunny Теперь, когда я подумал об этом (спасибо @zellyn за эту ссылку 😂), зачем нам нужен oauth-провайдер, _полная_ поддержка веб-перехватчиков, документация по API и _полный_ API для самостоятельного хостинга?

Требуется OAuth _Consumer_ (он объединен, насколько мне известно), чтобы люди могли войти в систему, используя аутентификацию github.
Дрон использует только крюки, так зачем нам другой?

Что касается API, не уверен, почему для самостоятельного хостинга это вообще требуется TBH :)

Я согласен с сокращением этого списка. Более ранний самостоятельный хостинг, скорее всего, поможет нам лучше расставить приоритеты :)

@bkcsoft, может быть, мы сможем настроить размещенный сайт и попробовать.

@bkcsoft Я обновил выпуск, ты это имеешь в виду?

-> Провайдер OAuth (#27) не закрыт

@экозан не закрыт, а нужных вещей"

Добавлены «Ограничения размера репозитория», поскольку у нас нет неограниченного хранилища на серверах...

Мое предложение по ограничениям:

• 0 организаций
• 3 репозитория
• 1 ГБ/репо

@bkcsoft Вы

Может быть, а может и нет, но _если_ это станет общедоступной услугой, мы не можем иметь ее без ограничений ;)

Я думаю, что тестирование достаточно важно, чтобы ограничения размера репо не обязательно были на критическом пути для самостоятельного размещения gitea. В первые несколько дней после перехода на gitea я столкнулся с несколькими упущенными функциями, которые заставили меня думать, что самостоятельный хостинг поможет сосредоточить усилия на выполнении этих задач. Gitea уже является фантастическим, очень удобным и высокопроизводительным инструментом — очень жаль, что вы не используете его сами. ;-)

Вместо того, чтобы зависеть от жестких ограничений размера, было бы полезно подумать о том, как будет администрироваться самостоятельный сервер, кто будет контролировать плохое поведение и какие инструменты им понадобятся. Например, ответвления участников проекта gitea должны поддерживаться на собственном сервере gitea. Это подвергает риску того, что пользователь разветвит gitea, а затем отправит варез на свой форк. Ограничения по размеру могут помочь предотвратить отправку больших двоичных файлов, но могут не помочь со списком паролей или номеров кредитных карт. Инструмент, который может помочь в этом случае, — это то, что обнаруживает чужие файлы по количеству строк различий или скользящему хэшу.

Приятным побочным эффектом наличия инструмента для определения размера изменений является то, что код может быть доступен в качестве опции для запуска во время отправки, чтобы пометить законные коммиты, которые в любом случае должны были быть разбиты на более мелкие части. (Связанное обсуждение способов сделать это: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759.)

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

Говоря о вехах, следует ли добавить эту проблему в 1.5.0?

@stevegt Нет, так как я думаю, что не все PR будут объединены / разрешены в 1.5.0.

Я удалил Repository Size Limits (#3658) из проблемы, так как это не повлияет на gitea, размещенный на Gitea.

Я удалил ограничения размера репозитория (# 3658) из проблемы, поскольку это не повлияет на gitea, размещенный на Gitea.

Здорово! Я уверен, что чем раньше Gitea примет себя, тем быстрее весь проект получит пользу от реального опыта и завоюет доверие и уверенность :)

@lafriks упоминает в другой теме:

Для самостоятельного размещения, вероятно, потребуется дополнительное финансирование / спонсорство для оплаты дополнительной виртуальной машины.

И @lunny спрашивает выше:

@bkcsoft Вы

Возможно ли объединить эти мысли в «Как насчет создания онлайн-сервиса Gitea, где люди платят, скажем, за частные репозитории?».

Если все сделано правильно, это должно генерировать средства для оплаты себя + публичные репозитории.

Как концепция, это кажется довольно хорошо пройденной землей. :улыбка:

Чтобы оперативно добавить в идею @justinclift ; время может быть правильным с текущими новостями о том, что Microsoft захватила GitHub.

@lafriks упоминает в другой теме:

Для самостоятельного размещения, вероятно, потребуется дополнительное финансирование / спонсорство для оплаты дополнительной виртуальной машины.

Я уверен, что будет финансирование со стороны сообщества или спонсорство со стороны организаций, чтобы сделать хостинг gitea возможным. Поскольку Gitea нетребовательна к ресурсам (да, GitLab, я смотрю на вас), это не будет иметь большого значения.

@mxmehl до сих пор было 5 человек, которые внесли свой вклад с тех пор, как opencollective был открыт в прошлом месяце: https://opencollective.com/gitea

@justinclift, поскольку Gitea - это исключительно сообщество для управления, мы никак не могли бы создать платные частные репозитории, поскольку это требует создания компании, работы с налогами и наличия штатного персонала для решения технических проблем.

@mxmehl до сих пор было 5 человек, которые внесли свой вклад с тех пор, как opencollective был открыт в прошлом месяце: https://opencollective.com/gitea

@techknowlogick Не знал эту страницу. Сейчас 6 ;)

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

При этом требуется уровень воли, чтобы это произошло + чтобы это продолжалось. Люди в любых необходимых ролях также должны быть хорошими хранителями (заслуживающими доверия, надежными, знающими).

Если нет интереса, то это все равно никуда не денется. То же самое, если невозможно согласовать подходящие типы «хранителей».

Судя по ссылке Open Collective, упомянутой выше, похоже, что некоторые исходные семена готовы. Это свидетельствует о том, что вокруг есть люди, которых считают хорошими опекунами. :улыбка:

@justinclift Я не говорю, что это невозможно, просто не на данном этапе, но в будущем это может произойти. В настоящее время, по крайней мере, я бы лучше сосредоточился на разработке новых функций Gitea и улучшении документации :) Так что любая помощь очень ценится, чтобы быстрее двигаться к этой цели.

Хе Хе Хе

Не беспокойтесь вообще @lafriks. :улыбка:

Первая цель — Gitea разместила Gitea с тех пор, как github женился на Microsoft. :)

Я думаю, что только # 2519 и # 3748 нуждаются в проверке и объединении, прежде чем мы закроем эту проблему.

@bkcsoft

Добавлены «Ограничения размера репозитория», поскольку у нас нет неограниченного хранилища на серверах...

Мое предложение по ограничениям:

• 0 организаций
• 3 репозитория
• 1 ГБ/репо

Я думаю, что с ограничением количества репозиториев мы можем добавить возможность установки для форка только существующих репозиториев для всех пользователей, не входящих в команду Gitea:

• 0 организаций
• 3 репозитория (разрешить только форки)
• 1 ГБ/репо

Я не думаю, что количество форков нужно ограничивать, оно в любом случае будет ограничено количеством репозиториев gitea org, так что это должно быть нормально.
Что касается размера репо, да, наверное, должны быть какие-то ограничения

Мы должны ограничить создание организаций, создание репозиториев, поэтому ограничение размера репо не является необходимой проблемой для Gitea, размещенного на Gitea.

Мы могли бы подумать о добавлении #3134 и #4302 (PR и выпуск обратных ссылок) в список предварительных требований для самостоятельного хостинга - может быть, я уникален, но наша собственная небольшая установка gitea стала громоздкой без этих обратных ссылок, как только мы добавили более несколько пользователей и проблемы. Мы смогли обойти это с помощью поиска задач, но это ограничено без глобального поиска задач (# 2434/# 3841).

@stevegt Хотя было бы неплохо иметь обратные ссылки, я не вижу, чтобы они блокировали переход на самостоятельный хостинг :)

@bkcsoft Достаточно

Недавно я услышал об усилиях https://teahub.io. Они хотят создать некоммерческую организацию. Разве Gitea не может использовать это, как только они будут готовы к настройке?

@jlelse Нет. Gitea установит автономный сервер (например, self.gitea.io) для размещения gitea и зеркалирования на github, gitlab или teahub и т. д.

@lunny Нам действительно нужны комментарии к коммитам, поскольку в настоящее время мы используем только комментарии к PR на GitHub?

@JonasFranzDEV Я имею в виду комментарии к

Я комментирую здесь, потому что # 4108 закрыт. Когда Gitea Patreon (или подобная Patreon альтернатива) поднимается, мне нужно знать об этом. Я буду способствовать. Я бы хотел, чтобы этот проект был реализован самостоятельно и получил дальнейшее развитие. Как только я перенесу все свои репозитории, я больше не буду тратить деньги на Github, я буду ежемесячно выделять их на Patreon.

@ryanburnette https://opencollective.com/gitea

@lunny похоже, что "Система одобрения" в начале темы может быть зачеркнута. (Вопросы соответственно закрыты и объединены)?

@mjmlvp Я думаю, ты прав. Я удалил # 996 # 2519, так как он не должен быть блоком этой проблемы. Мы настроим сервер для размещения наших разработок.

Есть новости по этому поводу?

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

Было бы неплохо добавить открытые проблемы для этого в список. На данный момент похоже, что все связанные вопросы и PR закрыты и объединены.

@skddc готово.

Для записи

открытые серверы gitea

• https://try.gitea.io/
• https://teahub.io/
• https://dev.sum7.eu/

не доверять никому. делать регулярные резервные копии

@giteauser Я не понимаю, насколько это актуально

@giteauser, и это касается самостоятельной разработки gitea, поэтому разработка gitea больше не должна происходить на github. Я до сих пор не понимаю, насколько это актуально.

О, я разместил это не по той проблеме, извините.

Таким образом, все необходимые функции должны быть реализованы сейчас. Можем ли мы получить новую версию и мигрировать?

Правильно, мы настроим экземпляр gitea для размещения разработки gitea.

Я думаю, что исправление проблемы с дампом добавление надлежащих функций восстановления также являются важной частью управления инфраструктурой самостоятельно размещенного gitea.

Если вы развертываете Gitea на Kubernetes, я могу порекомендовать Ark для резервного копирования и восстановления.

Вообще говоря, резервное копирование не должно быть блокирующей темой для самостоятельной разработки Gitea, потому что у всех обычно разные стратегии/программы резервного копирования, в зависимости от их выбора платформы, метода развертывания, существующих инструментов и т. д. должна быть только блокирующей проблемой для производственной готовности этого самого экземпляра.

@max-wittig Самостоятельный веб-сайт gitea будет работать на каком-либо общедоступном облачном провайдере. Они предоставят службу RDS и средство резервного копирования базы данных, а также некоторые функции резервного копирования диска, чтобы команда резервного копирования дампа не была проблемой зависимости. Команда dump предназначена для службы gitea с одним узлом. Конечно, мы должны исправить эти проблемы.

@skddc Это интересный инструмент, который мы можем рассмотреть.

Я очень надеюсь, что выпуск 1.8.0 станет версией, в которой gitea станет самодостаточным. Я лично хотел бы использовать его для своих собственных проектов, но я использую gitea только в качестве зеркала по той простой причине, что я недостаточно доверяю ему, если разработчики — вы, ребята, — даже не используют его для разработки gitea. Кроме того, я хотел бы предложить использовать gitea в своей рабочей среде, но не могу даже предложить это, потому что меня просто высмеют, когда я скажу: «о, кстати, это выглядит потрясающе, но разработчики gitea не используют это для их собственного проекта"...

Это не критика или способ подтолкнуть вас, ребята. Просто дам вам знать, что мне (и, вероятно, многим другим) будет сложно, когда дело доходит до использования gitea в качестве основной системы управления исходным кодом;)

Наконец, чтобы быть немного более конструктивным. Если вы ищете очень хороший (и дешевый) clous vps для резервного копирования или даже для размещения gitea, взгляните на hetzner https://www.hetzner.com/storage/storage-box Хотя для такой важной инфраструктуры, как Gitea вы, вероятно, захотите сделать резервную копию в двух совершенно разных местах (например, hetzner и digitalocean).

@markg85 мы работаем над https://gitea.com

Какие-нибудь новости о размещении gitea на gitea.com?

@zachdoty Все еще работаем над этим.

Я забыл что-то необходимое для перехода с github на gitea. Нам нужно переместить все данные (включая данные git, проблемы, комментарии, запросы на извлечение из github в gitea), но на самом деле я не нашел подходящих инструментов для этого. Я отправил PR о переносе репозитория с внешнего интерфейса на внутренний, см. # 6200, а также https://gitea.com/gitea/migrator следует объединить с gitea, потому что API gitea не позволит создать проблему с указанным номером индекса.

gitea-github-migrator может перенести почти все, если вы еще этого не нашли. Если чего-то не хватает, возможно, это можно туда добавить, так что в других проектах тоже есть хороший инструмент для миграции.

@skddc они на самом деле одинаковы.

Ах, извините. Не ходил по ссылке.

Как сказал @kolaente , мы предложили @jonasfranz перенести gitea-github-migrator на gitea.com, и я отправляю PR https://gitea.com/gitea/migrator/pulls/1, который хочет улучшить это. Но я нашел как сторонний инструмент, есть один недостаток. То есть сложно сохранить индекс выпуска как раньше. (Чтобы все ссылки по проблеме оставались доступными.) Поэтому я думаю, что лучше объединить инструмент миграции с gitea в пользовательском интерфейсе миграции.

Определенно было бы здорово, если бы внутренние ссылки в комментариях и т. д. могли быть сохранены. Также было бы здорово, если бы PR, происходящие из одного и того же репо, можно было бы импортировать как фактические PR, а не задачи!

Я добавил новую задачу Migrate a throughout github repository to gitea в содержание проблемы и перенес ее в 1.9.0, чтобы это не блокировало выпуск версии 1.8. Но я не думаю, что нам следует ждать выхода версии 1.9, так как gitea.com последует за мастером.

Готова ли продукция Gitea.com, например, стоит ли мне беспокоиться о том, что код будет храниться там и он будет потерян?

@BNolet мы создали кластер ceph из 6 машин для хранения репозиториев. Так что это не должно быть легко потеряно, так как все данные будут скопированы 3 раза. Мы работаем над созданием еще одной резервной копии через зеркало ceph. И так как git распространяется. Ваши коды всегда будут храниться на вашем диске или диске ваших коллег.

Вау, это фантастика! Ожидаете ли вы, что сможете стать полноценной альтернативой GitHub или Gitlab?

Я так не думаю. Основной целью gitea.com является размещение разработок gitea. Хотя мы не накладываем никаких ограничений на gitea.com, мы рекомендуем вам самостоятельно настроить размещенный экземпляр Gitea, поскольку это очень просто.

Есть ли причина не разрешать вход с помощью OpenID?

@lunny У меня есть один, и мне он нравится :D

Насколько вероятно, что CI/CD станет частью продукта Gitea?

@strk, просто забудь об этом. Включит вход OpenID.
Сама @BNolet Gitea будет использовать дрон в качестве основного CI/CD.

Получение ошибки 500 при попытке использовать параметр Github oauth на странице входа после того, как я отправлю запрос разрешений для приложения go-gitea на Github.

Должен ли я немного подождать, чтобы проверить флагманский экземпляр?

@jakimfett , это известная проблема. Вы можете попробовать дважды, и это нормально.

@strk, просто забудь об этом. Включит вход OpenID.

@lunny, так как сегодня он все еще был выключен, может быть, есть сценарий развертывания, который постоянно отключает его?

@jakimfett , это известная проблема...

Внесите редактирование с номером выпуска, и я буду следить за ним.

_edit(s): форматирование_

Codeberg — это бесплатный сервис на основе Gitea. Возможно, Gitea сможет установить там официальное зеркало. В настоящее время он отображается на https://codeberg.org/Codeberg/gitea.

Gitea будет размещаться на https://gitea.com/gitea/gitea , и мы переместили большинство других пакетов на https://gitea.com/gitea , а сам gitea находится в процессе разработки. Зеркало приветствуется в любом другом сервисе на основе gitea.

@lunny прокомментировал вчера:
Зеркало приветствуется в любом другом сервисе на основе gitea.

Как только вернусь с выходных, соберу актуальное зеркало.

Связанный:
Есть ли где-нибудь список зеркал, и мне добавить себя в него, или...?

@jakimfett Нет, но вы можете создать PR с новой страницей документов

Для лучшего обработчика пользователей при миграции gitea с github я хотел бы перенести это на версию 1.10, и я думаю, что мы должны реализовать https://github.com/go-gitea/gitea/issues/7293, прежде чем мы начнем миграцию.

Я был бы полностью за этот шаг, если бы он не был размещен в Китае или электронное письмо с активацией пришло за 10 минут.

Я был бы полностью за этот шаг, если бы он не был размещен в Китае или электронное письмо с активацией пришло за 10 минут.

Редактировать: видимо, я был неправ.

Судя по некоторым гуглям, IP-адрес gitea.com на самом деле находится в Японии, а не в Китае. Однако этот IP-адрес принадлежит Alibaba.

Мы используем mailgun.org для отправки почты. Я не знаю, почему он будет тратить 10 минут.

Наш облачный провайдер пожертвований — это Didiyun, который находится в Китае и предоставляет много машин. В настоящее время у нас нет другого выбора.

И первой целью gitea.com не станет сервис, подобный github.com или gitlab.com. Он будет размещать только сам gitea, и мы рекомендуем вам настроить экземпляр gitea на самом деле.

@programmerjake Это

Я не собирался отказываться от своего экземпляра, но мне не нравится, что этот проект опирается на инфраструктуру, подаренную китайской компанией, у которой почти нет репутации в прошлом или результатах поиска. Вы действительно не знаете, что они будут делать в будущем, или потребуют ли они сократить свое пожертвование, если вы не реализуете XY или ZA, или если они просто уйдут в один прекрасный день.
Вы, вероятно, знаете, что делаете, и я просто опасаюсь, но вы никогда не узнаете.

Почему китайская компания сделает это, а американская — нет? :)

И я китаец, и, возможно, вам следует быть осторожным. Когда-нибудь я могу украсть ваши коды. :)

Я думаю, что у меня может быть такой план, когда я запускал Gogs с тремя другими китайцами в 2014 году.

Я не собирался отказываться от своего экземпляра, но мне не нравится, что этот проект опирается на инфраструктуру, подаренную китайской компанией. Вы действительно не знаете, что они будут делать в будущем, или потребуют ли они сократить свое пожертвование, если вы не реализуете XY или ZA, или если они просто уйдут в один прекрасный день.
Вы, вероятно, знаете, что делаете, и я просто опасаюсь, но вы никогда не узнаете.

Это совершенно идиотский ответ.
Теперь я мог бы быть более открытым, поскольку я голландец, мы вроде как принимаем это. Вы тоже должны попробовать.

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

Однако США... напомню, что Github сейчас ограничил свои возможности из-за «торговой войны» между США и Китаем. Во всяком случае, в настоящее время США представляют больший риск для разработки свободного программного обеспечения, чем Китай. Черт возьми, @lunny , вероятно, даже

@lunny и команда разработчиков Gitea. Продолжай в том же духе! :)

И первой целью gitea.com не станет сервис, подобный github.com или gitlab.com. Он будет размещать только сам gitea, и мы рекомендуем вам настроить экземпляр gitea на самом деле.

Это то, что вы можете рассмотреть в будущем?

Пока этот проект с открытым исходным кодом, на мой взгляд, нет никакого риска для всего, что вы сказали.

У основного проекта нет риска, но есть у инфраструктуры. Нет никаких гарантий, что неизвестный, не заслуживающий доверия донор будет там в следующем месяце, независимо от того, приедет ли он откуда-нибудь или из Китая. GitHub будет здесь долгое время и никуда не денется так быстро.

Кроме того, если вся инфраструктура переместится в Китай, вся пользовательская база пострадает из-за разногласий между США и Китаем.

@lunny Что касается электронных писем, которые занимают ~ 10 минут, в моем случае на сервере моей компании есть мера защиты от спама, которая представляет собой таймер «остывания» (здесь 20 минут), в течение которого он временно отклоняет любые письма из неизвестных источников. Таким образом, если пользователь (я) впервые получает электронное письмо с этого домена (например, gitea.com), мой сервер ответит «попробовать позже» и запомнит эту комбинацию пользователя и домена. В следующий раз, когда gitea.com попытается доставить мою почту в ожидаемое время, сервер примет сообщение.
Очевидно, у нас настроены некоторые «надежные источники», такие как GMail, Hotmail и т. д., которым не нужен период обдумывания.

Люди, если вы хотите, чтобы в каждом регионе было больше инфраструктуры, пожалуйста, проголосуйте своим кошельком на https://opencollective.com/gitea.

@SuperSandro2000 Знаете ли вы, что Gitea — это не услуга, а _продукт_? Вы загружаете исходники, компилируете Gitea на своих серверах и устанавливаете его. Никакого подключения к хостингу Gitea не требуется.

если они потребуют сократить свое пожертвование, если вы не реализуете XY или ZA, или если они просто уйдут в один прекрасный день.

Нет никаких гарантий, что неизвестный неблагонадежный донор будет там в следующем месяце.

Несколько ответов на это: мы не стали бы принимать гостей в компании с плохой репутацией, и руководители Gitea доверились этой компании. Если они перестанут оказывать спонсорскую помощь или перестанут быть компанией, у нас есть варианты, и мы можем перейти в другое место.

вся пользовательская база пострадает из-за разногласий между США и Китаем.

Большая часть команды Gitea из Китая (но у нас также есть сопровождающие на всех других континентах), и если команда разработчиков не сможет получить доступ к коду, пострадает пользовательская база, поэтому нам нужна команда разработчиков, чтобы иметь доступ код. Мы создаем Gitea, чтобы им могли пользоваться все, даже пользователи, заблокированные на GitHub (после недавней волны запретов на GitHub многие из этих пользователей начали использовать Gitea).

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

Примечание о прозрачности: я заблокировал эту тему. Я не хочу прекращать этот разговор, однако его следует перенести в другое место, так как этот билет на github посвящен тому, какие улучшения необходимо внести в программное обеспечение для самостоятельного хостинга (а не в том, где мы размещаем).