On 08/27/2015 06:32 AM, Jeff Cody wrote: > (Added Eric back in to the CC list. Looks like he got dropped > somewhere along the way)
No thanks to mailman's inept behavior that thinks that it is okay to rewrite cc's to drop anyone that doesn't want duplicate email. But don't worry about it; I have my local mail setup to flag any message in-reply-to an earlier one where I was in cc, precisely to work around mailman stupidly dropping me from cc. [Ideally, I'd filter the duplicate messages on my side, and turn off the broken mailman setting server-side, but I haven't yet figured out how to get filters working on my side that do that correctly.] I'm hoping that mailman3 is not so inept, and that this list archives can migrate to hyperkitty/mailman3 in the not-too-distant future. > > Do you disagree with the requirements I listed above? If so, it would > be useful to begin the discussion around that. For ease of > discussion, I'll list them again: > > * Reserved namespaces > * Uniqueness > * Non-predictable (to avoid inadvertently creating a de facto ABI) Dan made the point that if a name is unpredictable, then we have to query to learn what name was assigned. But if you add two or more devices before querying, then you don't know which device has which name. Predictable might actually be better than non-predictable. Better still might be fixing things to where we add a global command line option that outright fails any attempt to create an unnamed object. The option would be off by default for back-compat. But management apps like libvirt can turn it on once they are prepared to name every object they create (which in turn may imply fixing any remaining interfaces that cannot name an object to add in that ability for management to pass in a name). Then there would be no unnamed objects, no ambiguity, and no need to generate names. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
