On Fri, Feb 7, 2014 at 3:02 AM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> So the second issue is what a PMC member is required to do before voting...
>
> As a PMC member you are required to
>
> 1. Download the source code package
> 2. Compile it as provided
> 3. Test the resulting executable on your own platform
> 4. Verify that the package meets the requirements of the ASF policy on
> releases
>
> Do we really have to personally do all that *by hand*?
Supervising an autopilot is a fine way to fly a plane, so long as you actually
complete all your checklists and are prepared to seize control when something
unexpected occurs.
Since we're programming computers, we're already using automation. Adding CI
is just adding more automation, and for functionality testing and platform
compatibility testing, CI is superior to having a handful of PMC members run
manual builds.
For IP review, I think you still need to download the source archive and check
it on your own hardware. I would want a local tool which...
* downloads the release candidate
* generates a list of files added or removed since the last release
* generates a diff of all changes since the last release
* verifies that the expanded source archive matches an export from the
version control tag
I'd then inspect the changes to make sure they passed muster.
* diff looks legit
* new files have proper licensing
* change log up to date
* etc.
With that kind of tooling, performing review on a weekly release schedule
would not be unduly onerous[1]. A rapid release cadence yields small deltas
which are comparatively easier to inspect.
> Why can we not have a trusted build server hosted on Apache hardware do the
> download of the source package, compile it as provided and run the automated
> acceptance tests (on a range of platforms), the RAT tooling and perhaps
> verify that the source code package matches what is in source control? The
> trusted build server could then report the results to the project mailing
> list and then the PMC members just need to confirm the build server said OK,
> review the commits between the last time they looked at the commits and the
> tag (which they know matches what is in the source bundle) and then vote +1?
I'm concerned about the idea of a "trusted build server". Central build
servers are extremely attractive targets.
Instead of a "build server", how about just a CI server which is subscribed to
detect release candidates appearing on dist.apache.org?
I think it's might be OK to have a central server create a source release
candidate (to be validated by PMC members on their own hardware in addition to
any validation performed by the server), but binaries are a no-go due to the
prohibitive cost and risk of maintaining secure build servers. That leaves us
not too far from where we are today, where for many projects an RM supplies
both the source archive and convenience binaries (which they assume the risk
for).
Marvin Humphrey
[1] Assuming everything goes well -- which it won't. But that's a separate
email.
