SBo is running in an old and solid fashion, for years, in the Slack way.

We could make things better if migrated to Github (or bitbucket).

1. Get rid of the maintenance works on server-side repos. That doesn't
   mean we cann't or dislike these things, just use good service.
2. Replace the submission process with pull request. I'm too lazy to
   make a submission like this. I've no idea how the admins deal with
   these compressed files.
3. Better issue tracking with Github's Issues feature.
4. Easier and more convenient collaboration, E-mails notifications, etc..
5. Other goodies of Github, like hooking with many other services like IRC.
6. Attract more Slackers. Lots of personal slackbuilds repos out there are
   on Github right now.

The cons is, maybe a bit queer for a Slackware project running on such a modern service?

well, nearly nobody of the submitters do a totally clean job, I mean in a way that we can take their stuff as pull requests (we have nearly always to fix something in submissions, also extra spaces) so IMHO it doesn't make much sense to use those (only an handful of submitters are capable of doing them completely correct so that we can push stuff as-is).

that being generally unuseful doesn't mean that in the past (and probably also in the future), in some situations (like during migration from one version of Slackware to the other, for example), on a personal basis (depending on the admin), we haven't accepted commit from github branches...
an excerpt from my .git/config

1 members found this post helpful.

Never heard about this before.
But this issue has nothing to do with the submission approach. I mean, for example, users issue a pull request to the develop branch, you admins still could refine the scripts, then merge into the working branch, the end user should use the SlackBuilds in those working branches.

but you already can use the working branches, just point your remote at git://slackbuilds.org/slackbuilds.git and its branches

http://slackbuilds.org/cgit/slackbuilds/

you can even use them with sbopkg (to use another branch instead of master, follow the instructions there and substitute the "master" string with the name of the branch that you want to use sbopkg with).

managing pull requests that you have to fix is more painful that our present submission process, believe me (I'm processing stuff with both methods), not to count the added value that we have with it and the associated database that makes browsing on the SBo site a pleasing experience (search keywords and sanity checks, for example)

BTW, everybody it's free to fork our repository on github and work there, I'm doing that too!

P.S. DISCLAIMER: what I'm expressing in this topic are my personal opinions that not necessarily reflect the ones of the others admins.

2 members found this post helpful.

Got it, thanks for the explanation. It's not that simple as I imagined. Just thought that if hosted on Github, most things will be convenient and efficient.

What I've understood now is that most of the scripts submitted have problems. Maybe some strict guidelines addressing these type of problems should be informed to the submitters. It's the thing regarding one's level of bash scripting and experience, the understanding of Linux filesystem hierarchy and package management. Probably this is why it's complicated to maintain the project.

http://slackbuilds.org/guidelines/
http://slackbuilds.org/templates/
http://slackbuilds.org/faq/
I suppose that, just like with everything else, people just need time to get on track...

1 members found this post helpful.

The ongoing problem with SBos is that care has to be taken to ensure packages have proper dependencies in the list to resolve as well as clean compiles, proper edits with sed, and proper patches are applied, as well as the beast of all beasties... package stability and security.

If you want to say it, just about as much care goes into publishing working SBos as Slackware itself, which mind you, is no small task. Ask Robby and the other major maintainers how much goes into testing SlackBuilds prior to publishing. You don't want a bad package in circulation.

I'll even 1-up that by saying that there are users of other distributions, like myself who use LFS/BLFS, and use SBo derived scripts for our own packages that normally don't have an entry in the book to work from.

So personally, it think SBo is fine as it is. Why risk screwing up an already good thing?

2 members found this post helpful.

I second that! +1! And thanks as always to the SBo maintainers!

I am not actually a github fanboy anyway. I find navigation on unfamiliar projects, and particularly getting to needed info somewhat difficult and tedious (but also maybe due to my own ancient habits).

SBo is a great resource, but lacks polish.

Overall, the system works pretty well. Once you spend the time gathering/creating and tweaking queue files, package generation is a breeze. Using sbopkg makes things even easier.

However, the initial amount of queue file work can be daunting. Most of the queue files I use were created by others, and I use that as a base. From that base, I tweak the queue files to include optional dependencies, change build options, etc..

For example, the ffmpeg slackbuild is very basic and I like to include many of the optional dependencies. This means that I must dig through the dependencies and include those queue files. It's a tedious process, especially for packages like MythTV and VLC, which have many dependencies. However, once you have a working set of queue files, maintenance is minimal. Jumping from 14 to 14.1 required a few changes to my queue files, since package names and requirements change, but it was minimal.

I would love to see an official SBo queue file repository, with all optional dependencies included for each package, but I realize this is a huge amount of work that never ends.

I like the submission process as it is. It is simple enough even for me...

Could you be specific about the errors in submissions? Could you possibly list in details a few most common ones so that next time we pay extra attention to it. You guys have enough work on your hands to fix our mistakes.

... or reject them with some explanation (eg. on the mailing list). Initially it'd be more work for you but next time people will be extra careful not to make the same mistake (or the mistake mentioned on the mailing list).

Just my thoughts.

Here are some common problems we found:
Not following the guideline and latest template are the most common thing
People often used their original submission instead of the modified script in our repository
Putting too many unnecessary information on the README and slack-desc
Wrong md5checksums

We don't want to spam your inbox with other people's problem, so we reply it personally for each submission if we think it's necessary. Otherwise we will just clean it up for you, but see second point above.

1 members found this post helpful.

This will make packages bloated just like other distribution, which is something we tried to avoid
We list the hard dependency in the .info file and list the known optional dependencies in the README. The decision is left for the user to pick

2 members found this post helpful.

This is pretty much what Portage is. You should try Gentoo.

can you please elaborate?

with the new sbopkg, Chess added a tool named sqg (you can find it in /usr/doc/sbopkg-0.37.0/contrib/sqg): the first thing I do on my installs is sync sbopkg making it download the repository, copy sqg to /usr/local/sbin/sqg, modify lines 47 and 48 with the data of the repository I'm using sbopkg with, and launch it with the -a option
and when it finishes I have all the queuefiles based on the selected repository in /var/lib/sbopkg/queues! \o/
then I add the optional dependencies I need or the necessary switches, parsing the README files, to the queuefiles it generates.

4 members found this post helpful.