Alright let's get back to school.
There's a thing called planning. Let's say you're making bricks for sell.
Before you start the production process you plan how much do you want them produced. Let's say 100. Once you hit 80 of them you can say "it's nearly done!" and grab a beer.
How could you say that something is "nearly done" if you don't have any idea how much of fixes are going to be in a patch, eh?
Dude, I already explained that in the post you're replying to. The brick metaphor you're using here is conceptually wrong, because a patch isn't a stack of identical items, it's a conglomeration of independent bits of code, most of which are completely independent if each other.
I'll try and walk you through it in a simple fashion. Let's say there are only five major things being worked on. Programmer A is implementing a walk toggle for PCs, programmer B is handling some console issue, programmer C is working on the face-altering thing, and so on. Theoretically you could just release five separate patches, but that's a QA and certification nightmare so nobody does it that way; not in gaming, anyhow. So you bundle them together into one download and call that a patch.
So, what happens if they're not all done at the same time? Do you hold up A, B, and E's fixes because C and D need a couple more weeks?