Pkg xen devel - Feb 2019 - Bug#768005: xl / xen bash completion

Hi!
> 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).

best regards,
    Adi

[1] https://xenbits.xen.org/git-http/xen.git
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xl_bash_completion.diff
Type: text/x-diff
Size: 8083 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190211/a1889c72/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190211/a1889c72/attachment-0001.sig>

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.

:)

Hans