Hi, On 2/12/19 2:27 AM, Hans van Kranenburg wrote: > Hi, > > On 2/11/19 2:01 PM, Adi Kriegisch wrote: >> >>> Reassigning to Debian Xen team, since I that makes more sense. We >>> totally missed this on our (release) radar. >>> >>> And indeed, we're shipping the upstream completion file now. Adi, I see >>> how you're improving it, and I like it. >> I'm happy you like it... >> >>> So, we should probably ship this instead, but at the same time, the >>> right (tm) place to move this is upstream. We're activetly trying to get >>> rid of "adjusted copies of upstream stuff" in the packaging. >> I think it would be great if you could ship that for Buster because I don't >> think upstream will merge it within the next month... ;-) >> >>> Would you mind making an upstream patch out of this? I can help with >>> that if needed. Then it gets proper review, and upstream can maintain it >>> when commands are added/changed etc. >> Find the patch attached; it is based on upstream's repository[1]. Feel free >> to submit it upstream (no need to credit me; this is just copied together >> from xm and upstream's command list). > > Well, there's the "two sides of the coin"... There's getting credits for > doing work, but you'll also get blame because the work is never good enough. > > It's nice that this improved completion script is adding things on top > of simple first-level commands, but when reviewing this, the first > command I looked at is xl create. My first question would be: did you > compare the actual current result to the xl man page? > > For example, I see that xl create has options like -q, --quiet, -f=FILE, > --defconfig=FILE, -p, -F, -V, --vncviewer, -A, --vncviewer-autopass, -c, > and (whoa!!) even key=value "It is possible to pass key=value pairs on > the command line to provide options as if they were written in the > configuration file"... Ok, that last one is probably a bit too much to > ask completion to have an opinion about, but... > > You get the picture. Your completion file just has options='-c'. > > What do you think would be the best to do with this? Have a thorough > review and comparison and add all possible options and test them? Or, > take a step back and pretend it can do less, like the upstream one? > > I can't just submit a patch upstream with myself as "credit" in this > state, because I know these are the questions that upstream developers > will be throwing at me immediately.
Initially, I thought that this file was already converted to xl, but that seems not to be the case. I do not think it's a good idea to include this, since it's simply doing an incorrect thing in many places, e.g. suggesting phy: obsolete syntax, but also the options just don't match xl. So, this needs someone who actually uses bash completion a lot, and wants to take ownership of this task, converting and testing everything and taking it upstream first. I'm not going to do that now, sorry. Hans
