[OpenAFS-devel] Re: OpenAFS Master Repository branch, openafs-stable-1_6_9-branch, updated. openafs-stable-1_6_8-73-gca0be5b

[Stephan Wiesand]

On Jun 12, 2014, at 23:55 , Jeffrey Altman wrote:

> On 6/12/2014 4:51 PM, Stephan Wiesand wrote:
>>=20
>> On Jun 12, 2014, at 22:09 , Benjamin Kaduk wrote:
>>=20
>>> On Thu, 12 Jun 2014, Gerrit Code Review wrote:
>>>=20
>>>> The following commit has been merged in the =
openafs-stable-1_6_9-branch branch:
>>>> commit ca0be5b2a69476cc577976fad0767dfbf8628857
>>>> Merge: 9492d2a 3381492
>>>> Author: Stephan Wiesand <stephan.wiesand@desy.de>
>>>> Date:   Thu Jun 12 10:52:09 2014 +0200
>>>>=20
>>>>  Merge branch 'security-1.6' into HEAD
>>>>=20
>>>=20
>>> I believe this commit was only pushed to the 1.6. 9 branch, and is =
not present on the openafs-stable-1_6_x branch (which should be fixed).
>>=20
>>=20
>> This is a long story not to be told ever. I hate security releases.
>>=20
>> What I think should happen is that we forget about 1_6_9-branch and =
merge gerrit 11283 (which is equivalent, except for the 1.6.9 version =
strings and a single line in NEWS, and that can be verified), and get on =
with life...
>=20
> I want to speak with Simon.  There are two alternatives.  The one
> that Stephan mentioned and a merge commit on openafs-stable-1_6_x =
which
> pulls in the two patches that make up 1.6.9.

Those merges are just ugly IMO. And they are only needed when we feel =
forced to do things behind gerrit's back. If we can avoid them, we =
should.

Cherry-picking the commit from the openafs-stable-1_6_9-branch =
(bc8f62fcdfa479023d15125404d1b13b6dfd6dc3) seems even better than just =
accepting 11283 to me.

> In either case nothing else should ever be committed on top of
> openafs-stable-1_6_9.

Not as it is, right. I'm wondering whether that merge commit could be =
reverted though, just in case we'd need a 1.6.9.1 (which is not too =
unlikely).

> This will be sorted out tomorrow.

Any news?

--=20
Stephan=