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.