about Slackware Packaging Project

这个SPP我发起在http://slackpkg.com/，目前主要发布slackbuild脚本，以后可以考虑增加做repo。

我不是用刚接触slackware时的那种激情做这件事，也不是脑子一热注册这个域名。
只是想用更“先进”的方式维护这些脚本，然后有条件做public的repo。让客户端的package应用更简单，有更多的选择。

总之一句话，希望志同道合的朋友一起为了Slackware及其社区做一些力所能及的事。

也欢迎诚恳的泼冷水，挑毛病。更欢迎转稿。

谢谢大家。
--
Cherife Li

可以看下slackcode.cn
跟站主联系下可能比较好

不错的项目啊～ 不过和 slackbuilds.org 有什么联系么？现在一般我写的脚本都是交给他们的，而且他们的几个管理员也是 slack 的开发者～

我觉得你应该先介绍一下你所说的更“先进”的方式，不然大家也不知道和slackbuilds.org的区别在哪，而slackbuilds.org现在已经有那么多资源，大家可能还是会习惯于slackbuilds.org。不知道你是想做成arch的abs那种型式还是什么呢？

跟SBo没有关系。SPP不与其他类似的repo冲突，只是让每一个slacker多一个选择。
至于“先进”，并不是真的很高级，只是更方便实用一些。
SPP用Trac写wiki＋Issue tracking，这样真的是很方便，用Mercurial作为repo的提交途径，这样任何有commit权限的ID都可以更新每一个slackbuild，让脚本的更新更加自如，及时和便捷。
有一点，如果完全开放repo的commit权限，恐怕会产生混乱，或者有捣乱份子，所以commit权限目前是集中管理的。

SPP是一个比较open的项目，汇集每个人的智慧和贡献，造福每一个slacker。

那和 SBo 有什么区别呢？我觉得他们的机制(maintainer + code review) 也不错～ 至少是现在还是够用的～

其实真的不想去跟某个repo或组织去比较个所以然出来，就算跟sbo一模一样再整一个出来，大家可以爱用不用，谁都可以理解，是吧。硬要跟SBo比较的话：

SBo：有些slackbuild的maintainer并不active，有些slackbuild甚至无人更新了。
SPP：每个项目成员都是maintainer，更灵活。

SBo：提交包之后要走pending queue，然后才能进repo，如果在pending queue阶段你想更新是无法再提交的，而且更新不及时，邮件列表里的repo update邮件更不及时，nginx有时候接连更新几个版本了，我上次提交的nginx还在pending。
SPP：直接进repo，实时更新，有改进意见直接修改。

SBo：有bug要用邮件沟通，很传统。
SPP：每个人随时都可以直接用Trac提交一个ticket，trac是个好东西。

SBo：repo用rsync同步，没有版本控制功能。
SPP：引入分布式的代码版本管理机制，使用mercurial维护。

大概就想到这几点。
我觉得如果用一下trac和mercurial之后，认识会更深入一些。而不是停留在感性认识上。

不多说什么了，搞得像在忽悠谁入伙一样。
对SPP最坏的打算是我一个人自娱自乐，仅此而已。