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 -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc