[CentOS-devel] working around stacked updates

[Karanbir Singh]

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