Agree with Felix, we should stay away from MAY especially if we want to achieve 
clarity for Oak-Core what it can expect the MK to do

On Dec 18, 2012, at 9:49 AM, Felix Meschberger wrote:

> Hi,
> 
> Just remember that "MAY" is difficult to handle by developers: Can I depend 
> on it or not ? What if the "MAY" feature does not exist ? What if I develop 
> on an implementation providing the "MAY" feature and then running on an 
> implementation not providing the "MAY" feature ?
> 
> In essence, a "MAY" feature basically must be considered as non-existing :-(
> 
> All in all, please don't use "MAY". Thanks from a developer ;-)
> 
> Regards
> Felix
> 
> Am 18.12.2012 um 09:37 schrieb Marcel Reutegger:
> 
>> Hi,
>> 
>>> To address 1) I suggest we define a set of clear cut cases where any
>>> Microkernel implementations MUST merge. For the other cases I'm not sure
>>> whether we should make them MUST NOT, SHOULD NOT or MAY merge.
>> 
>> I agree and I think three cases are sufficient. MUST, MUST NOT and MAY.
>> MUST is for conflicts we know are easy and straight forward to resolve.
>> MUST NOT is for conflicts that are known to be problematic because there's
>> no clean resolution strategy.
>> MAY is for conflicts that have a defined resolution but we think happen
>> rarely and is not worth implementing.
>> 
>> I don't see how SHOULD NOT is useful in this context.
>> 
>> regards
>> marcel
> 

Reply via email to