As with any situation in which there are products from two vendors
involved it is critical that bug reports be opened by affected customers
with both vendors.  Only by receiving a significant number of bug
reports can a vendor decide to prioritize a work around, fix or
other change.

A large vendor with hundreds of thousands or millions of customers is
unlikely to prioritize a change if they determine that a small number of
customers would benefit.  This is especially true if the change would
impact a larger number of customers in some adverse way.

In this particular situation I am aware of several cases that have been
opened with Red Hat.  There can never be too many.

Jeffrey Altman


On 3/12/2014 12:49 PM, Renata Maria Dart wrote:
> Thanks Andrew...we'll see what we can find out.
> 
> Renata
> 
> On Wed, 12 Mar 2014, Andrew Deason wrote:
> 
>> On Wed, 12 Mar 2014 08:19:22 -0700 (PDT)
>> Renata Maria Dart <[email protected]> wrote:
>>
>>> Hi Andrew, we opened a ticket with RedHat, but it is
>>> not clear how to proceed....are you thinking that we 
>>> should be asking them for a fix? 
>>
>> If you're concerned about this, the way I would frame the discussion
>> with them is that you're asking if Red Hat can provide a workaround in
>> their kernel. One possible way they can maybe achieve that is to remove
>> the referenced change, since I am not really sure what this fixes (or
>> what its motivation was):
>>
>> [RHEL5]
>>>> - [fs] vfs: stop d_splice_alias creating directory aliases (J. Bruce 
>>>> Fields) [785916]
>> [RHEL6]
>>>> - [fs] vfs: stop d_splice_alias creating directory aliases (J. Bruce 
>>>> Fields) [820446]
>>
>> Alternatively, they can engage us in conversation about how OpenAFS can
>> more easily avoid this. J. Bruce Fields is already discussing this a
>> little on openafs-devel, so you could just point them at that or the
>> referenced central.org RT ticket.
>>
>> -- 
>> Andrew Deason
>> [email protected]
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> [email protected]
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
> 
> _______________________________________________
> OpenAFS-info mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to