Вменяемый линк с гитхаба

Да, некоторые разработчики не понимают смысла релизов и версий.

а какой в них смысл (для _приложений_ в себе, конечно, про важность версионности либ никто не спорит) во времена гитхабов?

Тогда можно обходить этот вопрос с помощью прямого обращения к фиксированным коммитам.

о чем и речь, даты-номера коммита вполне достаточно

Релиз предполагает завершенность, делит поток непрерывный коммитов на какие этапы с понятным смыслом.

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

делит поток непрерывный коммитов на какие этапы с понятным смыслом.

тебя Йода покусал?

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

Необязательно конечно это должен быть релиз мажорной версии

на минорные делить ещё сложнее

Про git clone уже говорили?

тебя Йода покусал?

есть немного )

с «гитхабовской» моделью разработки достаточно сложно делить на эти самые этапы

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

Не, конечно разные ситуации бывают и пакеты типа NetworkManager-0.9.4.0-9.git20120521.fc17.x86_64 встречаются достаточно часто. Но если я буду делать пакет какого-то софта, то первым делом попрошу разработчика обозначить какой-нибудь хоть самый минорный релиз, чтобы у пакета была четкая отправная точка.

делай просто регулярные, раз в два месяца, например.

либо от балды, как некоторые (не будем тыкать пальцем), ага. Только смысл тогда в них?

Ох уж эта ваша слака...

Смысл релиза в подведении черты.

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

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

И я так подозреваю судя по обсуждаемой теме ты арчевод. Так вот заметь даже в модели rolling-release такие опорные точки все равно создаются:

Sure we have a rolling release model, but still our isos/img's are definitely not «just» a snapshot:

• they are planned
• we work «towards» them and provide support afterwards
• we do a core freeze a while before, and during the release.
• they are carefully tested.
• we time releases of other packages/tools to «fit» in the iso release scheme (eg installer)

Ой ля-ля, он дебианщик. Правда сидит на Sid-е, зачем ему debian с таким подходом — нипанятна. :)

Ну надо же, и такое бывает ))

Я не понял, в чём проблема?

Ну раз не понял кури в лукморе что такое линк :-)

зачем ему debian с таким подходом — нипанятна.

единственная проблема «с таким подходом» в дебиан - относительная сложность написания спеков для сборки (после фряшных портов поначалу было не очень комфортно, но вполне терпимо, тем более что по структуре они в чём-то схожи - мейкфайл отдельно, патчи отдельно, описание отдельно).

А вот профитов полно: хорошая автоматизация всего и вся (кстати, не сразу заценил этот плюс, поначалу так и норовил везде руками залезть), куча скриптов на все случаи жизни, мультиплатформенность (одним и тем же дистром пользовался/уюсь на x86, x86_64, ppc, mipsel и arm), три полноценные ветки почти на все случаи жизни (да, изредка даже в sid/experimental нет свежей версии чего-нибудь, но с тем софтом что использую я - никаких проблем нет), гибкие зависимости, возможность тырить пакеты-спеки из PPA-моек.

Да и sid в основном использую по привычке, для работы сейчас вполне хватило бы и stable. Просто случайно 4 года назад натолкнулся на sidux - понравилось, с тех пор и пошло.

судя по обсуждаемой теме ты арчевод

как уже написали - нет

даже в модели rolling-release такие опорные точки все равно создаются:

на Sid конечно влияет период заморозки, но не так критично (ведь есть experimental)

our isos/img's are definitely not «just» a snapshot:

у Sid просто нет официальных iso даже в виде снэпшота

ну итп

не знаю, как в гит, но на битбакете и hg можно так https://bitbucket.org/user/prj/get/tip.zip. tip всегда будет указывать на последний комит. Может быть, и на гитхабе есть что-то подобное?

Это есть и на гитхабе, вопрос в том что нужна опрtделенная версия, для которой будет постоянна mdsum

а вы сделайте форк на нужной версии на том же гитхабе и сделайте архив в разделе downloads :)

Ээ, малость неэтично :-)

почему? Вы же не присваиваете авторство, лицензии не нарушаете. Назовите проект gmediafinder-slackbuilds. Впрочем, правильней, конечно, ссылаться на нужный комит

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

__стырить__ какую то прогу
С лицензией все в порядке,

это что же за лицензия такая? :) И с каких это пор форки на гитхабе стали неэтичны? Посмотрите внимательней, весь гитхаб из подобных проектов и состоит

Из того что «многие делают», вовсе не следует «многие делают этично» :-)

ТС извращенец он делает слакбилд для нестабильного пакета аля ebuild-9999.

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

Даже если он и удовлетворит их желание, то в слаке уже есть такой пакет последней версии

http://pkgs.org/slackware-13.37/slacky-i486/gmediafinder-0.9.9.1-i686-1sl.txz...

«милый мальчик» © :-) пакет собирается для 14 слаки с другим питоном, это раз, ну а два, вот тебе фраза от Robby Workman из рассылки
Anyway, once you have addressed these points, please resubmit
this (after Slackware 14.0 is released); I'd love to add it
to our repo.

Так что гуляй :-)

Добавить нужный файл в downloads?

Ну так об это все три страницы :-) , как получить нужный линк типа github/file-bla-bla.tar.gz на определенную версию проги с постоянной mdsum

Дядя напишите автору программы владельцу репозитория на гитхабе чтобы он выложил для Вас tar.gz

Хватит писать на лор по всякой чепухе.

Каждый проект имеет следующую ссылку: https://github.com/user/project/downloads

Добавьте туда свой файл.

Так не я автор этой проги. Каким образом я туда добавлю этот архив ?

Форк?

Неэтично как то

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

Ну так это проблемы гитхаба и автора. Если гитхаб предоставляет такую возможность, а автор не выпускает релизов или кладет их только в ppa, тот почему нет ? Тут сложно сказать что лучше, брать сорцы с ppa или с гитхаба.

К тому же я просто не знаю как воспримут линк на сорцы с ppa на slackbuilds.org, там принято что линки даются на сайт автора, гитхаб в данном случае. В редчайших случаях, к которому данный скорее всего не относится, можно дать какой то левый линк, но все таки это не приветствуется

Чарующая своей увлекательностью история.

Не я придумал такие требования :-) Где то они может и не совсем логичны, но они есть

Что же тут нелогичного-то?

Ссылка дается не затем, чтобы было откуда скачать исходники. Их можно вон на rghost выложить, но мы же не для этого пакеты делаем.

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

Вообще то да, тут и неэтично и нелогично.