<div dir="ltr"><div>Hello Developers & administrators;</div><div><br></div><div>I spend quite a bit of time on release testing to make sure my users are not surprised in a negative way, and I was wondering if we could help each other increase our own productivity as I'm sure a lot of duplication of effort is going on.</div>
<div><br></div><div><div>Following google's developer motto: <i>We aren't better at making software than anyone else. We just have more data about how it is used.</i> </div><div><br></div><div>I think this is true, with the difference, that we could, but are not, using our data systematically.</div>
</div><div><br></div><div>The request for +1 votes:</div><div>Could we - the people - benefit from creating a release testing package which permits/shows the following behaviour:</div><div><ol><li>We <u><i>select a group of users</i></u> who use the "current" version[1] actively.<br>
</li><li>When a "release version" comes becomes available for testing it may run in a virtual environment, literally cloning the signals that the selected users perform, without reverse impact on their repositories. It may even run with a predetermined delay (if appropriate) to replicate activity.<br>
</li><li>At given intervals, a comparison is made between the users "current" version and the "release version", to verify a relevant list of metric's [2]</li><li>The comparison is f.x. automatically submitted as a test reports to the administrators (or OCteams) mailbox (or whatever is more convenient). In this way we do not replicate our tests but actually run them collectively with collective knowledge being gathered. </li>
</ol></div><div>Notes:<br></div><div>At [1]: These could be selected by the administrator or - more long term - we would ask a profiler to select the users who use a very wide range of features so that the solution space of the test gets as close to exhausted as possible.</div>
<div>At [2]: I would imagine something like: </div><div><ul><li>comparison of sets of sha1sum of files "stable" vs. "release" of the selected users (integrity).<br></li><li>bandwidth usage "stable" vs. "release" (comm. load)<br>
</li><li>process time "stable" vs. "release"<br></li><li>statistics from the logs in aggregated form from "stable" vs. "release".<br></li><li>...<br></li></ul></div><div>Would this be valuable to others too?<br>
</div><div><br></div><div>@OCteam: This could give the possibility that users can "click to upgrade to version x.x.x+1 instead of being foie gras fed with push from the administrator for a "grace period". I know from reports that this is a key user appreciation with google's systems, as the user "who doesn't have time for this upgrade right now, can opt-out for a grace period". <br>
</div><div><br></div><div>@RaspberryPi Users: Don't panic about memory footprint, I'm sure we can figure out a way to disable this dual-environment if the memory footprint doesn't allow it.</div><div><br></div>
<div>Kind regards,</div><div><br></div>-- <br><div>Bjorn Madsen</div><div><i>Researcher Complex Systems Research</i></div><div><a href="mailto:bjorn.madsen@operationsresearchgroup.com" target="_blank">bjorn.madsen@operationsresearchgroup.com</a></div>
<div><br></div>
</div>