Re: dput: Call for feedback: What should change? What should stay the same?

[Ben Finney]

Barry Warsaw  writes:

> Unfortunately, the documentation you find on extending upload
> permissions to DMs doesn't tell you that only dput-ng supports the dm
> subcommand.

Likewise, I'm having no luch finding comprehensive reference
documentation for commands accepted by ‘dak’.

Is there a bug report I've missed which addresses this?

-- 
 \ “I still have my Christmas Tree. I looked at it today. Sure |
  `\   enough, I couldn't see any forests.” —Steven Wright |
_o__)  |
Ben Finney

Re: dput: Call for feedback: What should change? What should stay the same?

[Barry Warsaw]

On Dec 28, 2016, at 10:25 AM, Steve Langasek wrote:

>Last I looked, the dcut command in dput doesn't support the 'dm' subcommand;
>this led me to switching to dput-ng when I needed it.

Same here, as I recently needed to `dcut dm` allow for a maintainer of a
package I had been sponsoring while he went through the process.
Unfortunately, the documentation you find on extending upload permissions to
DMs doesn't tell you that only dput-ng supports the dm subcommand.

That's about the only difference I've noticed so far, so I'd be happy enough
to switch back if dput also had a dm subcommand (although truthfully, I rarely
use that anyway).

I think it's fairly confusing that there's dput and dput-ng and would love to
see functional and cli convergence so that eventually there's only one package
that supports current use cases.

Cheers,
-Barry


pgpJv0ozO18GG.pgp
Description: OpenPGP digital signature

Re: dput: Call for feedback: What should change? What should stay the same? [and 1 more messages]

[Andreas Tille]

On Fri, Dec 30, 2016 at 07:07:31AM +1100, Ben Finney wrote:
> 
> Much appreciated. Yes, one aspiration I eventually hope to achieve have
> is to resolve the fork by merging the desirable features of both back
> into ‘dput’, and discarding behaviour that we decide is no longer
> helpful.

Freedom of choice sometimes turns out as burden of choice if its about
such a simple thing as uploading data on the command line.  I was always
wondering why we need two tools and the `dcut dm` feature was my reason
to choose dput-ng.

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: dput: Call for feedback: What should change? What should stay the same?

[Tobias Frost]

Am 28. Dezember 2016 05:31:39 MEZ, schrieb Ben Finney :
>Howdy all,
>
>I recently donned the mantle of maintaining ‘dput’ and am carefully
>making improvements. I am conscious of the special need for backward
>compatibility so I am taking care to understand how the Debian
>developer
>community uses it today.
>
>So I'm now familiar enough, but still fresh enough, that feedback from
>people with different experiences is particularly valuable.
>
>
>What does ‘dput’ do that you think really should not be changed?
>
>What does ‘dput’ do that you wish it would stop doing?
>
>What do other tools do better than ‘dput’? Do you think that ‘dput’
>should change to do those tasks the same way?
>
>
>The same questions can be asked of the ‘dcut’ program from the same
>package.
>
>The ‘dput-ng’ package is one alternative that is sometimes suggested
>when people hit the limits in ‘dput’. I am not a user of ‘dput-ng’ or
>other alternatives, so am also seeking feedback from people who have
>informed positions on choosing one over the other.
>
>Both newcomers and old hands are welcome to give responses on these
>questions.

I'd like to see #791828 fixed and make it possible to habe dput and dput-ng 
installed the same time.

-- 
Tobias Frost
GPG fingerprint: 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7 

Re: dput: Call for feedback: What should change? What should stay the same? [and 1 more messages]

[Ben Finney]

"Paul R. Tagliamonte"  writes:

> FWIW, I don't think any of the dput-ng hackers particularly mind if it
> changes, changing API could just happen for both together, at the same
> time. Or maybe just consolidate :)

Much appreciated. Yes, one aspiration I eventually hope to achieve have
is to resolve the fork by merging the desirable features of both back
into ‘dput’, and discarding behaviour that we decide is no longer
helpful.

-- 
 \   “Corporation, n. An ingenious device for obtaining individual |
  `\   profit without individual responsibility.” —Ambrose Bierce, |
_o__)   _The Devil's Dictionary_, 1906 |
Ben Finney

Re: dput: Call for feedback: What should change? What should stay the same?

[Ben Finney]

Russ Allbery  writes:

> I have never managed to work out how to use dcut […] in fewer than
> five tries each time I've needed to use it. I'm not sure what it is
> with that command, but I find it completely baffling to use correctly.

This should be addressed by, at least, improving the ‘dcut(1)’ manual
page so that it properly describes how to use the existing interface.
I have reported bug#849687 for this.

A broader discussion can be had on changing the ‘dcut’ interface; I
leave that as an exercise for the future. Suggestions are welcome
though.

-- 
 \  “In case of fire, do your utmost to alarm the porter.” —hotel, |
  `\Vienna |
_o__)  |
Ben Finney

Re: dput: Call for feedback: What should change? What should stay the same? [and 1 more messages]

[Paul R. Tagliamonte]

FWIW, I don't think any of the dput-ng hackers particularly mind if it
changes, changing API could just happen for both together, at the same
time. Or maybe just consolidate :)

Paul

On Dec 28, 2016 4:34 PM, "Ian Jackson" <ijack...@chiark.greenend.org.uk>
wrote:

> Ben Finney writes ("dput: Call for feedback: What should change? What
> should stay the same?"):
> > So I'm now familiar enough, but still fresh enough, that feedback from
> > people with different experiences is particularly valuable.
>
> Thanks a lot for seeking input.  I'm not a very advanced user of dput,
> personally, but:
>
> As you will know, dgit calls dput.  dgit doesn't really care whether
> dput is dput-ng, but I need them to be "compatible enough".  Also,
> dgit very much wants dput not to fail, because that would be an
> inconvenient late failure.  Checks (such as running lintian) should
> come earlier, which means that dgit needs to do them somehow.  #827879
> and #840249 refer.
>
> Any improvement there would leave a similar issue with dput-ng,
> probably.
>
> (Frankly, I think it is wrong to do something like a lintian or suite
> check _after_ the signature has been made.  Checks should be done
> before signature.  So any such checks in dput ought to be redundant.)
>
> Christian Seiler writes ("Re: dput: Call for feedback: What should change?
> What should stay the same?"):
> > I only use dput-ng, but because of the extra checks that has already
> > saved me from performing a wrong upload; the check in question is that
> > the Distribution: field in the *.changes file matches the distribution
> > in debian/changelog.
>
> I can't resist saying that dgit checks that :-).
>
> Ian.
>
> --
> Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
>
>

Re: dput: Call for feedback: What should change? What should stay the same? [and 1 more messages]

[Ian Jackson]

Ben Finney writes ("dput: Call for feedback: What should change? What should 
stay the same?"):
> So I'm now familiar enough, but still fresh enough, that feedback from
> people with different experiences is particularly valuable.

Thanks a lot for seeking input.  I'm not a very advanced user of dput,
personally, but:

As you will know, dgit calls dput.  dgit doesn't really care whether
dput is dput-ng, but I need them to be "compatible enough".  Also,
dgit very much wants dput not to fail, because that would be an
inconvenient late failure.  Checks (such as running lintian) should
come earlier, which means that dgit needs to do them somehow.  #827879
and #840249 refer.

Any improvement there would leave a similar issue with dput-ng,
probably.

(Frankly, I think it is wrong to do something like a lintian or suite
check _after_ the signature has been made.  Checks should be done
before signature.  So any such checks in dput ought to be redundant.)

Christian Seiler writes ("Re: dput: Call for feedback: What should change? What 
should stay the same?"):
> I only use dput-ng, but because of the extra checks that has already
> saved me from performing a wrong upload; the check in question is that
> the Distribution: field in the *.changes file matches the distribution
> in debian/changelog.

I can't resist saying that dgit checks that :-).

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: dput: Call for feedback: What should change? What should stay the same?

[Christian Seiler]

Hi there,

On 12/28/2016 06:18 AM, Afif Elghraoui wrote:
> but the dput
> command from dput-ng does some spurious checks that fail and I've never
> found worth the time to investigate.

I only use dput-ng, but because of the extra checks that has already
saved me from performing a wrong upload; the check in question is that
the Distribution: field in the *.changes file matches the distribution
in debian/changelog.

I don't know which checks in dput-ng fail for you (for uploads that
were OK dput-ng always worked for me), but the plausibility checks are
a large reason why I really wouldn't want to switch to dput at the
current time.

Also, I remember vaguely that when I first started uploading, dput
didn't support a specific setting in dputrc that dput-ng did (I don't
remember which one though), so I never actually used dput because of
that. (Sorry, but it's been a while and I really don't remember what
precisely that was, and maybe that has already been fixed in the mean
time.)

That said: I personally don't really care about the underlying
implementation - so I'll just use the one which I consider to be
better - and at the moment that would be dput-ng, but that could
easily change.

Regards,
Christian

Re: dput: Call for feedback: What should change? What should stay the same?

[Steve Langasek]

On Tue, Dec 27, 2016 at 11:11:02PM -0800, Russ Allbery wrote:
> Ben Finney  writes:

> > What does ‘dput’ do that you think really should not be changed?

> > What does ‘dput’ do that you wish it would stop doing?

> > What do other tools do better than ‘dput’? Do you think that ‘dput’
> > should change to do those tasks the same way?

> I'm not the best person to give feedback on dput since I switched over to
> dput-ng completely and have never looked back.  But I suppose that's a
> data point from one user who greatly appreciates the changes in dput-ng
> and would be happy to have that be the default dput.

> I am kind of meh on the JSON configuration format for dput-ng, though.

> I have never managed to work out how to use dcut (from either dput or
> dput-ng) in fewer than five tries each time I've needed to use it.  I'm
> not sure what it is with that command, but I find it completely baffling
> to use correctly.  Usually I manage to find some way to name the wrong
> thing in the command, refer to it incorrectly, or pick the wrong way to do
> whatever I'm trying to do.  And I use it so rarely that I never remember
> what mistakes I made the next time I try.

Last I looked, the dcut command in dput doesn't support the 'dm' subcommand;
this led me to switching to dput-ng when I needed it.  The actual behavior
differences between the two implementations of the 'dput' command all seem
negligible.

I agree that the dcut command is largely unusable.  dput-ng's 'dcut --help'
doesn't not actually document the usage of the command (to go by the output,
no subcommands are supported at all, let alone there being documentation of
the arguments of subcommands, and why in the world does 'dcut rm' take its
arguments as '-f ' instead of as further positional arguments), and
the fact that dcut dm requires an up-to-date local *DM* keyring to match
against instead of letting you use your GPG keyring is irksome.

So if dput were to implement a saner dcut command I would gladly switch
back.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: dput: Call for feedback: What should change? What should stay the same?

[Russ Allbery]

Ben Finney  writes:

> What does ‘dput’ do that you think really should not be changed?

> What does ‘dput’ do that you wish it would stop doing?

> What do other tools do better than ‘dput’? Do you think that ‘dput’
> should change to do those tasks the same way?

I'm not the best person to give feedback on dput since I switched over to
dput-ng completely and have never looked back.  But I suppose that's a
data point from one user who greatly appreciates the changes in dput-ng
and would be happy to have that be the default dput.

I am kind of meh on the JSON configuration format for dput-ng, though.

I have never managed to work out how to use dcut (from either dput or
dput-ng) in fewer than five tries each time I've needed to use it.  I'm
not sure what it is with that command, but I find it completely baffling
to use correctly.  Usually I manage to find some way to name the wrong
thing in the command, refer to it incorrectly, or pick the wrong way to do
whatever I'm trying to do.  And I use it so rarely that I never remember
what mistakes I made the next time I try.

-- 
Russ Allbery (r...@debian.org)   

Re: dput: Call for feedback: What should change? What should stay the same?

[Afif Elghraoui]

Hi, Ben,

على الثلاثاء 27 كانون الأول 2016 ‫20:31، كتب Ben Finney:
> Howdy all,
> 
> I recently donned the mantle of maintaining ‘dput’ and am carefully
> making improvements. I am conscious of the special need for backward
> compatibility so I am taking care to understand how the Debian developer
> community uses it today.
> 

Many thanks for soliciting users' perspectives. I think this isn't done
as often as it should be, so I very much appreciate it.

> So I'm now familiar enough, but still fresh enough, that feedback from
> people with different experiences is particularly valuable.
> 
> 
> What does ‘dput’ do that you think really should not be changed?
> 
> What does ‘dput’ do that you wish it would stop doing?
> 
> What do other tools do better than ‘dput’? Do you think that ‘dput’
> should change to do those tasks the same way?
> 
> 
> The same questions can be asked of the ‘dcut’ program from the same
> package.
> 
> The ‘dput-ng’ package is one alternative that is sometimes suggested
> when people hit the limits in ‘dput’. I am not a user of ‘dput-ng’ or
> other alternatives, so am also seeking feedback from people who have
> informed positions on choosing one over the other.
> 

I always have to use dput-ng in order to be able to use the dcut dm
command and grant DMs upload permissions. That works well, but the dput
command from dput-ng does some spurious checks that fail and I've never
found worth the time to investigate. What I end up doing (since it
doesn't happen very frequently) is switching back to plain dput, which
simply does the job. If I ever have to grant upload permissions, I
install dput-ng, do the dcut dm, then install plain dput again.

So as far as I'm concerned, if the dput package had a dcut that supports
the dm subcommand, I'd be very happy.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

dput: Call for feedback: What should change? What should stay the same?

[Ben Finney]

Howdy all,

I recently donned the mantle of maintaining ‘dput’ and am carefully
making improvements. I am conscious of the special need for backward
compatibility so I am taking care to understand how the Debian developer
community uses it today.

So I'm now familiar enough, but still fresh enough, that feedback from
people with different experiences is particularly valuable.


What does ‘dput’ do that you think really should not be changed?

What does ‘dput’ do that you wish it would stop doing?

What do other tools do better than ‘dput’? Do you think that ‘dput’
should change to do those tasks the same way?


The same questions can be asked of the ‘dcut’ program from the same
package.

The ‘dput-ng’ package is one alternative that is sometimes suggested
when people hit the limits in ‘dput’. I am not a user of ‘dput-ng’ or
other alternatives, so am also seeking feedback from people who have
informed positions on choosing one over the other.

Both newcomers and old hands are welcome to give responses on these
questions.

-- 
 \“Good judgement comes from experience. Experience comes from |
  `\  bad judgement.” —Frederick P. Brooks |
_o__)  |
Ben Finney