Увидел свет (http://lists.sfconservancy.org/pipermail/kallithea-general/2...) второй выпуск системы управления репозиториями Kallithea (https://kallithea-scm.org/), основанной (http://www.opennet.me/opennews/art.shtml?num=40141) энтузиастами и представителями организации Software Freedom Conservancy с целью продолжения развития свободной кодовой базы RhodeCode, после превращения (http://www.opennet.me/opennews/art.shtml?num=37626) данной платформы в полупроприетарный коммерческий продукт. Kallithea позволяет развернуть инфраструктуру управления разработкой, которая поддерживает системы контроля версий Git и Mercurial, и по решаемым задачам напоминает GitHub, GitLab и Bitbucket. Код проекта распространяется (https://kallithea-scm.org/repos/kallithea/) под лицензией GPLv3. Код проекта написан на языке Python.Kallithea включает в себя высокопроизводительный сервер обработки push/pull-запросов и веб-интерфейс для организации совместной разработки, который позволяет управлять репозиториями, разделять права доступа, рецензировать код, отслеживать активность других участников, делать форки проектов, отправлять пулл-реквесты или изменять код на месте, через простой редактор. Поддерживается интеграция с централизованной базой пользователей предприятия, основанной на LDAP или ActiveDirectory. Поддерживается создание групп репозиториев и групп разработчиков с унификацией управления членами группы. Внешний вид интерфейса может легко быть изменён через систему шаблонов. Поддерживается наглядное представление активности в виде графиков. В системе рецензирования изменений поддерживается обсуждение изменений и отправка уведомлений.
Серверная часть платформы является многопоточной, что позволяет одновременно обслуживать несколько pull/push-запросов. Для увеличения производительности в системе активно используется кэширование и выполнение действий в асинхронном режиме. В систему также интегрированы средства резервного копирования, позволяющие периодически архивировать и сохранять через scp копию всех данных. Для отслеживания активности в репозиториях поддерживается специальная прослойка, ведущая журнал всех обращений и позволяющая аутентифицировать каждый запрос. Для работы с репозиториями задействована библиотека vcs (http://pypi.python.org/pypi/vcs), мета-данные о проектах могут хранится в БД на основе SQLite, PostgreSQL или других, поддерживаемых SQLAlchemy.
В новом выпуске улучшена система обработки запросов на изменение (pull request). Проведена модернизация интерфейса. Задействованы новые символические значки из наборов FontAwesome и GitHub Octicons. Проведена адаптация интерфейса для экранов с высоким разрешением (HiDPI). Добавлена поддержка особенностей новых выпусков Mercurial 3.3 и Dulwich 0.9.9. Применены оптимизации кода работы с СУБД, которые позволили значительно повысить производительность некоторых операций. Обновлены используемые JavaScript-библиотеки jQuery, CodeMirror и Mergely. Проведена чистка кода JavaScript и файлов CSS.
Кроме того, в Kallithea 0.2 устранены две уязвимости (https://kallithea-scm.org/security/). "CVE-2015-0260 (https://kallithea-scm.org/security/cve-2015-0260.html)" - позволяет через манипуляцию с get_repo API получить доступ к репозиторям с привилегиями других существующих пользователей. "CVE-2015-0276 (https://kallithea-scm.org/security/cve-2015-0276.html)" - позволяет через проведение CSRF-атаки получить неаторизированный доступ к аккаунту пользователя, осуществившего вход в систему, если данный пользователь перейдёт по подготовленной злоумышленником ссылке.URL: http://lists.sfconservancy.org/pipermail/kallithea-general/2...
Новость: http://www.opennet.me/opennews/art.shtml?num=42019
Хорошая альтернатива GitLab. Ещё бы Django использовали, совсем бы хорошо было. А то начали вылазить детские ошибки, типа полного отсутствия защиты от CSRF.
Так ведь в Джанге нет асинхронной работы, на которой сейчас они сосредоточились. Мы вот тоже сейчас засматриваемся на aiohttp, jinja уже туда привязана, но csrf еще ручками.
Джанга с gevent прекрасно работает.
у них в фичах уже Cerey:
>>"Optional async tasks for speed and performance using celery"а gevent это быть завязанным на 2.Х версии питона. В том же 3.4 и далее asyncio
мда, UI конечно жутко проигрывает Gitlab в плане юзабилити и интуитивности начало работы.
Поможете улучшить? Мы патчи принимаем :)
Пока намерений нет. Но так как ГитХаб стал по сути доминирующим облачным средством совм. разработки, с огромной юзербазой, нужно максимально интерфейс сделать под него.По коду самой системы, то что на базе pylons конечно же не будет способствовать притоку новых патчей от огромной массы Django разработчиков.
Делать клон гитхаба в плане интерфейса? Мда. И кто-то ведь таких клованов слушает.
issue tracker, хотя бы самый примитивный, туда бы добавили...
Неплохо, как альтернатива Гитлабу.
>Серверная часть платформы является многопоточнойЯ пропустил тот момент когда это из обыденного явления стало достоинством?
Мельчает девелопмент. Скоро приложения самостоятельные станут совсем в редкость и всякое гомно из Web будет более популярно, а наличие Standalone приложения станет редкостью и фишкой.
Обязательно нужен еще один вариант "системы управления репозиториями", но что б не мелочиться, уже тогда на js, bash .... больше интерпретаторов.....
ааааа, как же я мог забыть по пых....
Вот рассказ о проекте от одного из авторов (русскоязычного). https://vimeo.com/106435828