On Aug 27, 2015, at 9:00 AM, Eric Blake wrote: > 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.
Its also more user-friendly. > 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. I do agree with giving every device an ID, but I don't think failing if the user forgets to give one is necessary. If libvirt doesn't give devices and ID, it would probably benefit from having QEMU do it for libvirt.