32 bit vs Git My thought.
 

Weird label. Who really needs 32 bit.
Then let them build it.
Fact is time for Pat to keep source on a server.
Fact is time is part of time is space.
fact is 90 percent of code is one or another git.
Create your "source" git Pat.
Your build scripts git pull and tar then build.
Been doing it for years.
This is how I kept up with Alien Bob Ktown and used newer libraries.
This is how admin many of my builds.
Create a Git Source folder and like google been doing for years.
You can even pull the launchpad way in.
it is still your source blob that can be move forward and back.
And then you can charge for a source DVD bro.
Your killing your self Pat.
Your shoveling snow in a blizzard bro.
Stable current source and testing source.

when I seen this
I said omg this guy loves work get him some glasses.
Git ready it is a tool
How many floppies do you need when we actually live in the internet.
Download speeds we are already paying for it.
But your work can be forked and thousands can push and pull into you.
Last time I used a Real to Real was 1978.
time is now.

drop yourMinus the tarballs.
And then it would be under 7 gigs for a dvd 32 bit and 64.
your source already have changes with patches .
My thoughts.
for a note
Put it in your source.
World is one big link.

lovemeslk you made my day :-) Can you really think that Pat doesn't already use git repos? let me give you a hint: https://git.slackware.nl/current/

PS and OT: Maybe you beat me but just by a few months: if all goes according to the plans I will be 72 soon.

Too much wine with dinner?

Or perhaps it's past the usual time for your afternoon nap?

That is my setup, Pat has nothing to do with it.

Eric I stand corrected, sorry for the confusion and thanks for your script. Have a good day.

Yes I know he does. Sorry please forgive me. Make my self clear this was to handle the distribution of "source" file issue on upcoming release.
Thank you for reminding me and others. Love what you have done Didier. Your contributions are wonderful.

I'd be highly surprised if Pat isn't using some form of version control. Maybe he's old school and stuck with cvs or svn or maybe he migrated something newer like git. He might even have the code hosted on a public website like github, but has the repo marked as private. I also suspect that his close contributors (Alien Bob, rworkman, ppr:kut, drmozes, and possibly others) have access to at least a portion of the behind the scenes work that's being done. I also imagine that Pat has things very private that even his dev team don't have access to.

Slackware's development has always been behind closed doors. Pat is very aware of what changes could come from providing a publicly available version control, but he feels this is the right decision for what he envisions his Slackware to be. I'd love a more formal interface that allows bug reporting (although, this leaves people to report bugs on things that aren't actually bugs) and some form of way to submit changes (like Github's pull request).

This is a simple piece of code so that if he updates the source in the parent directory, nothing needs to be done to (attempt to) build the newer version. If the SlackBuild doesn't need any modifications, then that piece of code means he just drops a new source tarball in the directory, run the SlackBuild, and he's done. This is instead of manually changing the SlackBuild or passing VERSION=whatever to the script. I'd make a similar change to my SlackBuilds on SBo if it were allowed... one less thing to worry about in a version bump.

bassmadrigal
I understand that I am sure that tool serves him well.
I think the drop a tar in and readme is a good thing.
It has saved tons of editing. No denying it works well.

What I disagree on as I my self have used this tool is
the idea of making your personal tar balls for many apps can create ton of work.
I see tons of work. I am sure it is his joy.
I bet he may have a nice tool to help with that.

Slackware tradition of using the developers code and building it as they wanted.
I like the idea of it coming direct from the repo. As many do.
Sorry if I was not clear.

Trying to scale down the source part of the
media that will be released with Slackware 15.
This would leave more room on the media.
Or better yet just sell thumb drives because cdrom world has passed.

Your method may be good in your mind, but, fact is, we don't know the workflow of Pat behind the scenes. He may have something in place that simplifies him doing version bumps that you don't understand. I created a simple bash script that automates most of my version bumps for the SlackBuilds I maintain. It now takes just the time for my script to download the source and run the md5sum hash to do version version bumps, where before, it took a lot of manual work to do it.

You say he is "killing himself" without knowing the behind-the-scenes. He may have a system like SBo's .info files that contain all the needed info and a script to easily bump versions (that don't need new options) and the script might automate rebuilding those version bumps. Then he simply publishes the SlackBuilds, patches, and source to a mirror.

Since you can't see his process, you have no idea how much he is "killing himself". Or maybe he prefers that. Some users don't like to use automation, and there's nothing wrong with that as long as they have the time to do it.