On 08/27/2015 09: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. >
Can we add the information into the QMP response? > 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. >
