Feature changed by: Sascha Peilicke (saschpe) Feature #308836, revision 4 Title: performance: scaling ... - Buildservice: New + Buildservice: Rejected by Sascha Peilicke (saschpe) + reject reason: Unrealistic, reasons given. Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: Build performance should scale, in proportion to the number of users, and not the number of build nodes. Put another way - providing a means to apply local CPU horsepower to the channel, combined with some approach (eg. an xdelta to the previous built binary RPMS) to overcome the (typically) assymetric bandwidth availability in a typical DSL client - easy to download a reference to diff against, hard to up-load it. I would love to donate my CPU resource to help accelerate the projects I care about; as - no-doubt would others. Of course - this has security implications, which are (most likely) more or less meaningless. We ship binaries (re-)built from internal, signing servers anyway, and we have an authentication structure in place: if paranoia reigns, we could restrict that to a further subset of privileged users. Discussion: #1: Michael Meeks (michael_meeks) (2010-01-22 14:12:19) Again, please re-consider. There are many circumstances where the risk is really low. If you trust all the people in the commit chain - there is simply no issue: surely. eg. people trust openSUSE released versions, and their updates - because we have great quality, and (of course) because the packages are signed. If I have a home repository eg. that I trust the committers to, building against only signed repositories, I see no reason why there is any security issue whatsoever with me building my own binaries, with my own CPU power, for my own home channel. Fundamentally though - if we cannot scale our build horsepower in proportion to the number of our users, surely, we will just choke in the end however well we design the system. Would you really not let people choose the level of security risk they are willing to tolerate, and build locally on their machines (in a chroot jail or whatever). + #2: Sascha Peilicke (saschpe) (2010-12-17 16:06:55) + As you said, this depends on trust. Sure, we may trust the majority of + our users, but that doesn't mean that no one abuses this. There's no + guarantee to not get arbitrary trash send back instead of a working + package. The result would have to be tested/checked sent through + ClamAV, you name it. + SETI let's several users process the same set of data and then compares + the results. While this mitigates some of the mentioned risks, it's a + lot of processing again ... -- openSUSE Feature: https://features.opensuse.org/308836