[CentOS-devel] working around stacked updates

Tue Jun 24 18:24:48 UTC 2014
R P Herrold <herrold at owlriver.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 24 Jun 2014, Johnny Hughes wrote:

> > Will the 'as dropped' kernel and each intermediate kernel 
> > discussed by upstream in a RHSA, etc be published?  What is 
> > the plan as to anaconda integration?

> So that means we can build both kernels from git ... one to put onto the
> iso, the other one (now two after we apply the same changes to the new
> kernel-3.10.0-123.4.2.el7)
> 
> These kind of changes will only happen when Red Hat imports 2 versions
> in before we have a chance to modify the first version ... which will
> only likely happen on point releases?

It is of course a black box to outsiders as to WHO is making 
such commits into the git.centos.org image, when they are all 
mashed together without commit history.  The 'initial drop' 
seemingly was from another git, but eliding all commit 
comments and differentiation as to who the committer was, date 
of same, etc.

One assumes RHT Release Engineering and others inside RHT have 
commit rights on that tree ... the trick in understanding the 
security model and ability to dis-aggregate who committed what 
without history

It was clearly not, as some have opined, a simply unroll of 
SRPMs and import, as there are several packages with no spec 
file present.  List in the file:
	https://github.com/herrold/tool-tips/blob/master/clefos/fixup-dist.sh
in the second 'HERE' document.  The first outlines spec files 
needing dist tagfixup

How does one obtain commits in the centos 'git' tree?  I 
understand the model at Github, and am of course well willing 
to receive pull requests

- -- Russ herrold

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlOpwnUACgkQMRh1QZtklkSdNACfU5CRoflhtPEKNE6bldgbILgL
330AoITrB+ayD+7OFAaPiGEHI9y33LcK
=FvGy
-----END PGP SIGNATURE-----