Building is just one part of this. We also have to think about source control and test infrastructure.
For read access, a git repo is all or nothing, so I presume we'll need a system where we handle embargoed code in a separate, locked-down git repo (not just a branch) and merge that in after the embargo lifts. Can we make this work with gitblit? Can we make such a workflow tolerable in centpkg?
Similarly, with test infra we'll need mechanisms to test the embargoed builds without making them visible.
The access controls for all of this will have to line up.
Speaking of access controls. How fine grained do we need this to be? One big "access to embargo" group? Per-sig? Per-package? Finer?
As far as the build system goes, I see a few options: 1) separate (small) koji instance for embargoed builds. This would only really work for a coarse grained access plan 2) a reimzul instance as kb suggests 3) modify koji to support read access controls (highly nontrivial and invasive, but maybe we could do it anyway)
On Wed, Mar 11, 2015 at 12:54 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/11/2015 04:03 PM, George Dunlap wrote:
What does CentOS do about security patches on the core? Does it strive to have updates built and tested as soon as the embargo is lifted?
depends on the code- in some cases, where upstreams are going to work with us we do pre-patch and stage content that we can control code for - this tends to mostly be content outside of the distro.
For the distro itself, we rely on the source drops from upstream - but we dont really test or need to own too much of the code lifecycle there.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel