hi,
Working around stacked updates is an interesting issue. eg. Kernel needed patches into the GA release, for us to hit our GA tree, but it had also been updated for the zero-day update.
We want to make sure that all our sources are in the git tree's as well, and the only way to make that happen - that I could find sane anyway - was to branch, do the work on the GA tree and then merge back into the c7/ branch past the Zeroday update.
Might sound odd, but its fairly simple in implementation, the final merge is done back to the c7/ branch with a merge -s ours; so it wont retrofit older content in, but still merge the branches.
this is now live at https://git.centos.org/summary/rpms!kernel.git - I've attached the visual path for the repo via gitk to this email.
- KB
On 06/24/2014 12:14 PM, Karanbir Singh wrote:
hi,
Working around stacked updates is an interesting issue. eg. Kernel needed patches into the GA release, for us to hit our GA tree, but it had also been updated for the zero-day update.
the latest kernel update from upstream dropped into git a short while back, https://git.centos.org/log/rpms!kernel.git/refs!heads!c7 and it seems to slot in quite nicely with the git path so far.
So unless there are any objections in the near future, I would say we have a process that allows us to arbitarily work on older content, in side branches without stamping on c7/
On 06/24/2014 10:58 AM, Karanbir Singh wrote:
On 06/24/2014 12:14 PM, Karanbir Singh wrote:
hi,
Working around stacked updates is an interesting issue. eg. Kernel needed patches into the GA release, for us to hit our GA tree, but it had also been updated for the zero-day update.
the latest kernel update from upstream dropped into git a short while back, https://git.centos.org/log/rpms!kernel.git/refs!heads!c7 and it seems to slot in quite nicely with the git path so far.
So unless there are any objections in the near future, I would say we have a process that allows us to arbitarily work on older content, in side branches without stamping on c7/
Works fine for me, I can tell what is pushed content and what is modified content. The only suggestion I would have is for the last commit for a version, we get the NVR in the commit name. (ie, it would have been better if revision 315459 had 3.10.0-123.el7 in the commit message and if f355f5 had 3.10-0-123.1.2.el7 in the commit message.
But other than that minor comment, the process seems great.
And It is not hard to see the flow even without that, so it "works for me".
On 06/24/2014 05:15 PM, Johnny Hughes wrote:
On 06/24/2014 10:58 AM, Karanbir Singh wrote:
On 06/24/2014 12:14 PM, Karanbir Singh wrote:
hi,
Working around stacked updates is an interesting issue. eg. Kernel needed patches into the GA release, for us to hit our GA tree, but it had also been updated for the zero-day update.
the latest kernel update from upstream dropped into git a short while back, https://git.centos.org/log/rpms!kernel.git/refs!heads!c7 and it seems to slot in quite nicely with the git path so far.
So unless there are any objections in the near future, I would say we have a process that allows us to arbitarily work on older content, in side branches without stamping on c7/
Works fine for me, I can tell what is pushed content and what is modified content. The only suggestion I would have is for the last commit for a version, we get the NVR in the commit name. (ie, it would have been better if revision 315459 had 3.10.0-123.el7 in the commit message and if f355f5 had 3.10-0-123.1.2.el7 in the commit message.
But other than that minor comment, the process seems great.
And It is not hard to see the flow even without that, so it "works for me".
I was thinking about that - part of the challenge is then going to be howdo we implement that with the git-am flow. If the patches are already in and their commit messages are already set ...
otherwise, totally agree - having dupe commit messages is a bit annoying, and it needs a git branch patch visualisation to workout where the stuff came from and what srpm it applied to.
ofcourse, not a problem for people not needing to edit content retrospectively ( hopefully that will be us, once C7 is out of the door).
- KB
On 06/24/2014 11:17 AM, Karanbir Singh wrote:
On 06/24/2014 05:15 PM, Johnny Hughes wrote:
On 06/24/2014 10:58 AM, Karanbir Singh wrote:
On 06/24/2014 12:14 PM, Karanbir Singh wrote:
hi,
Working around stacked updates is an interesting issue. eg. Kernel needed patches into the GA release, for us to hit our GA tree, but it had also been updated for the zero-day update.
the latest kernel update from upstream dropped into git a short while back, https://git.centos.org/log/rpms!kernel.git/refs!heads!c7 and it seems to slot in quite nicely with the git path so far.
So unless there are any objections in the near future, I would say we have a process that allows us to arbitarily work on older content, in side branches without stamping on c7/
Works fine for me, I can tell what is pushed content and what is modified content. The only suggestion I would have is for the last commit for a version, we get the NVR in the commit name. (ie, it would have been better if revision 315459 had 3.10.0-123.el7 in the commit message and if f355f5 had 3.10-0-123.1.2.el7 in the commit message.
But other than that minor comment, the process seems great.
And It is not hard to see the flow even without that, so it "works for me".
I was thinking about that - part of the challenge is then going to be howdo we implement that with the git-am flow. If the patches are already in and their commit messages are already set ...
otherwise, totally agree - having dupe commit messages is a bit annoying, and it needs a git branch patch visualisation to workout where the stuff came from and what srpm it applied to.
ofcourse, not a problem for people not needing to edit content retrospectively ( hopefully that will be us, once C7 is out of the door).
Right .. we could, I think, do a 'git commit --amend' after the "git am" to edit the commit comment, I think (before doing the next SRPM in the set) .. then do the second set after that amend edit.
On Tue, 24 Jun 2014, Karanbir Singh wrote:
So unless there are any objections in the near future, I would say we have a process that allows us to arbitarily work on older content, in side branches without stamping on c7/
I may be not understanding what you are saying
A centos 7.0 gold, set of installable images (which inclide kernel in the anaconda) are not yet emitted. Prior practice was to pick a kernel level, and to integrate / stabilize** that ** kernel at time of 'drop' into the anaconda, knowing full well that a clutch of updates would come cascading in immediately after the install at firstboot
This was useful, as it is not all that uncommon to "exclude=' the kernel updates from the yum setup. I have a laptop which has not been able to take a kernel update since C6.3, for example, as the LCD backlight code is not working in later versions
Indeed, I had to search back through several kernel initial release and updates during debugging
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?
-- Russ herrold
On 06/24/2014 11:35 AM, R P Herrold wrote:
On Tue, 24 Jun 2014, Karanbir Singh wrote:
So unless there are any objections in the near future, I would say we have a process that allows us to arbitarily work on older content, in side branches without stamping on c7/
I may be not understanding what you are saying
A centos 7.0 gold, set of installable images (which inclide kernel in the anaconda) are not yet emitted. Prior practice was to pick a kernel level, and to integrate / stabilize** that ** kernel at time of 'drop' into the anaconda, knowing full well that a clutch of updates would come cascading in immediately after the install at firstboot
This was useful, as it is not all that uncommon to "exclude=' the kernel updates from the yum setup. I have a laptop which has not been able to take a kernel update since C6.3, for example, as the LCD backlight code is not working in later versions
Indeed, I had to search back through several kernel initial release and updates during debugging
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?
-- Russ herrold
Right, but git went past that update ... as their were 2 commits back to back .. the GA kernel and the zeroday update kernel.
The goal here is to do mods to the GA kernel to put on the ISO, get those mods into git using the GA kernel and also not erase the Zero Day kernel info ..
so these 3 changes are to GA kernel:
16 hours ago Karanbir Singh update changelog for the debranding changes 315459 diff | tree
16 hours ago Jim Perrin Add two small patches for kernel debranding. Addresses arch/x86/kernel/setu... d96cc7 diff | tree
16 hours ago Karanbir Singh Patch in CentOS SecureBoot keys df32f9 diff | tree
while these 2 are to the Zero Day Kernel:
16 hours ago Karanbir Singh Merge branch 'c7-GA' into c7 f355f5 diff | tree
16 hours ago Karanbir Singh Patch in CentOS SecureBoot keys 0b2610 diff | tree
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?
Thanks, Johnny Hughes
On 06/24/2014 11:50 AM, Johnny Hughes wrote:
On 06/24/2014 11:35 AM, R P Herrold wrote:
On Tue, 24 Jun 2014, Karanbir Singh wrote:
So unless there are any objections in the near future, I would say we have a process that allows us to arbitarily work on older content, in side branches without stamping on c7/
I may be not understanding what you are saying
A centos 7.0 gold, set of installable images (which inclide kernel in the anaconda) are not yet emitted. Prior practice was to pick a kernel level, and to integrate / stabilize** that ** kernel at time of 'drop' into the anaconda, knowing full well that a clutch of updates would come cascading in immediately after the install at firstboot
This was useful, as it is not all that uncommon to "exclude=' the kernel updates from the yum setup. I have a laptop which has not been able to take a kernel update since C6.3, for example, as the LCD backlight code is not working in later versions
Indeed, I had to search back through several kernel initial release and updates during debugging
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?
-- Russ herrold
Right, but git went past that update ... as their were 2 commits back to back .. the GA kernel and the zeroday update kernel.
The goal here is to do mods to the GA kernel to put on the ISO, get those mods into git using the GA kernel and also not erase the Zero Day kernel info ..
so these 3 changes are to GA kernel:
16 hours ago Karanbir Singh update changelog for the debranding changes 315459 diff | tree
16 hours ago Jim Perrin Add two small patches for kernel debranding. Addresses arch/x86/kernel/setu... d96cc7 diff | tree
16 hours ago Karanbir Singh Patch in CentOS SecureBoot keys df32f9 diff | tree
while these 2 are to the Zero Day Kernel:
16 hours ago Karanbir Singh Merge branch 'c7-GA' into c7 f355f5 diff | tree
16 hours ago Karanbir Singh Patch in CentOS SecureBoot keys 0b2610 diff | tree
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)
The other 2 into the updates repo, that should say ...
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?
-----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
I currently don’t understand anything of what is happening on git.centos.org. Seems far too complicated for me.
I don’t understand why a « rhel7 » branch does not exist… I think it would be simpler for everyone. Red Hat would simply put new sources on that branch, then CentOS developers would merge it with c7.
And it would certainly help to shut down this stupid controversy about « Red Hat taking the control of CentOS ».
Guillaume Derval.
Le 24 juin 2014 à 20:24, R P Herrold herrold@owlriver.com a écrit :
Signé partie PGP 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
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/24/2014 01:24 PM, R P Herrold wrote:
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.
I have no idea where the initial import comes from ... All I know is it comes from Red Hat.
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
Again, I don't know. It comes from Red Hat. Someone else will need to comment on that. From my perspective, this initial commit is just like a RHEL SRPM. Something from Red Hat that I trust explicitly.
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
SCLs are not some we are building yet. To be honest, I haven't even looked at one of those in the tree yet. I just picked one and looked at it, it seems to have a spec file just fine:
https://git.centos.org/tree/rpms!php55/a6d9c8fb3b8b211a9df1cdf49ccd6c54c4de6...
Once CentOS-7 is released, we will begin work on CentOS-7 SCLs
Other things listed:
We had redhat-release-server from RHEL 7 RC in our tree initially to be able to build things, that require was later met with a version of centos-release.
The SRPMS redhat-release*, redhat-indexhtml, redhat-logos, Red_Hat_Enterprise_Linux-Release_Notes* are not going to be released in CentOS ... they are blacklisted. centos-release, centos-indexhtml, centos-logos will replace the redhat-* ones, Red_Hat_Enterprise_Linux_Release_Notes* will just not exist in CentOS.
I see no issues with esc, haproxy, OpenEXR, or any of the others you list with no spec, example:
https://git.centos.org/tree/rpms!esc/b795a4fef7d3400e969f7897b6dbf7c00e9b343...
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
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/24/2014 11:39 PM, Johnny Hughes wrote:
I have no idea where the initial import comes from ... All I know is it comes from Red Hat.
I was going to blog about this and writeup a dedicated piece, I might still do that if it helps clear the air a bit but in a nutshell :
- we created a directory and did a PoC by importing the rhel7beta and rhel7rc code, this demostrated how the system was going to work and if the system was going to work
- the RH release team have built their own tools around howto manage the code and howto push changes, making only one request from ourside that non fast-forward merges not be pushed into the git repos at /rpms/, which makes sense ( ie. they are likely NOT pulling in our changes into their systems ). I say 'their' to imply the RH release team systems, not Red Hat.
- The git repos at git.centos.org are a source representation of the sources they push, its not a working or devel source tree that will get in-process developer commits, this tree gets content to match the content pushed out via their release process.
- For us, in the centos project and the community at large, these repos become the canonical upstream to target our builds from. And they will host our developement and in process content.
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
Again, I don't know. It comes from Red Hat. Someone else will need to comment on that. From my perspective, this initial commit is just like a RHEL SRPM. Something from Red Hat that I trust explicitly.
That is my understanding as well, and having walked the tree a couple of times now, we are fairly confident that every import into the git tree's is repackageable as srpm should that be the format of choice for downstream consumption.
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
Do you have an example of a git repo that does not have a SPEC file ? I had an arbitary look at a few on that list, and they all seem fine to me. Its possible to checkout c7; get_sources.sh; rpmbuild -bs ... -> srpm.
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
The best way to onramp there is to post git format-email patches to this list and we can curate them as is, in the git repo if needed. That also means that further mod's down the road can just be cherry picked from the patch stack on updates.
- KB
-
Guillaume Derval -
Johnny Hughes -
Karanbir Singh -
R P Herrold