P2P Packaging/Koji Cloud

[夜神 岩男]

On 12/08/2011 05:12 AM, seth vidal wrote:
> Bandwidth is the big concern for the end user here and then the other
> issue is  - is all of this worth it for building pkgs? I don't think it
> is, personally, pkg building is not that huge of a hit, afaict to
> getting things done.
>
> I mean the sum total of the steps were talking about, even now is more
> or less:
>
> 1. init host
> 2. stuff some files onto it
> 3. start up a process
> 4. communicate to that process
> 5. build pkg
> 6. stuff pkgs into a local repo
> 7. go to 5 until no more pkgs
> 8. download all pkgs back to original client
> 9. destroy host.
>
> you can do it now if you're willing to do steps 5-8 manually.

I think you are correct in essentially asking if this is a solution in 
search of a problem.

But on the technical side...
I don't think bandwidth would be much of an issue, for one thing it 
could be throttleable and with a huge number of available systems this 
still results in an overabundance of available systems for build. And 
anyway most Fedora users have no problem sucking down a DVD-sized spin 
each time they want to try something other than the default desktop.

If this were implemented the entire cycle should be per package or 
perhaps per some limit of packages that is user-configurable (like "do 
blocks of 10 rpms" or "do blocks of packages > 500Mb && < 1Gb"). With 
parceled building like that the iterations are smaller but more 
frequent, and I think less of a burden for someone who just wants to try 
things out.

And on the practical side...
This all goes back to the first sentence in this response. While it is 
very possible to do something like this, and the idea is exciting 
because it is something new, I've never heard of anyone kicking and 
screaming about a wait que bottleneck or insufficient resources in the 
Fedora infrastructure. I've also not heard anything like "RH is going to 
drop Fedora so we need to look for a new home", either. I was simply 
addressing the "how to make it secure" element. This is a workable 
method which relies 100% on volunteers (i.e. community resource use, not 
a paid solution) VS going to some overwrought cloud solution for which 
there really isn't any backstop for integrity checking compared to the 
distributed build crosscheck I've described above.