[Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris]

[Danek Duvall]

On Tue, Feb 26, 2008 at 03:11:17PM +0100, Roy Lyseng wrote:

> Java API: The commitment level for the Java API was classified as 
> Volatile in LSARC/2007/385. Based on recent discussions, I am open for 
> reclassifying this as Uncommitted, if this is the ARCs opinion.

Ah, okay.  If you're comfortable that the interfaces are sufficiently
stable to be considered Uncommitted, then that's fine, and the ARC would
generally prefer that building blocks like APIs be Uncommitted or better,
but committing too strongly to an interface is problematic, too.

> Dtrace probes: My apologies for not having discussed this. A separate 
> mail is being sent to dtrace-discuss at opensolaris.org ASAP.

Thanks.

> > As for putting the commands in /usr/memcached/bin, we thought that
> > names like 'memcat', 'memstat', 'memerror', etc. *are* too generic, and
> > were preempting complaints about such commands in /usr/bin.
> > 
> > I think the project team would be happy to locate them in /usr/bin.
> 
> I have a concern with the utility names too (I would really see them
> merged into a single utility with subcommands), but of course it is
> simpler for us to put everything into /usr/bin...

Yeah, I was thinking that they'd make for good subcommands, too.  What does
memcached do in its default installation?  What do Linux distros do with
these utilities?  I would suggest that you ping the memcached community and
see if they'd be willing to accept a change modifying these commands to be
subcommands of a wrapper.  But if they've been around a long time and
reasonably consistently delivered in /usr/bin as-is, then they might not be
terribly open to that.

If they *were* willing to accept such a change, then you could integrate
them as-is in /usr/bin now (as Volatile or Obsolete), and change them
later, when you get the changes integrated in mainline memcached.

I'm not going to push you too hard in that direction, though.

Danek