On Thu, Apr 30, 2009 at 07:23:56PM -0700, Jordan Brown wrote: > Nicolas Williams wrote: > >On Thu, Apr 30, 2009 at 04:02:36PM -0700, Jordan Brown wrote: > >>I would accept that as an answer for my problem. That'd be nice - no > >>code changes, just documenting the idiom. Formally it's still take an > >>ARC case to guarantee that it'd work. > > > >Why? To guarantee that this behavior of rpcgen does not change? It's > >not already effectively Committed? PSARC's take would be that rpcgen is > >Committed. > > Every aspect of it? It's really pretty rare that every aspect of a command > is Committed.
That's not how PSARC acts with respect to interfaces like this. First you'd have to do ARCeology to find if any ARC case exists for rpcgen, and if you do find one, then map the old interface stability to the new taxonomy, and either way, PSARC would look at the history of the thing. Finally, there's no need to run an ARC case for this. Instead, if anyone wanted to change rpcgen in a backwards incompatible way it would be their burden to show that such a change should be allowed and to update whatever consolidations to fix any uses of the broken interfaces. In other words: it's safe to use any _documented_ feature of rpcgen. Nico --
