bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnupload --help examples


From: Ralf Wildenhues
Subject: Re: gnupload --help examples
Date: Sat, 28 Nov 2009 08:04:30 +0100
User-agent: Mutt/1.5.20 (2009-08-09)

Hi Karl,

I agree with most everything you wrote (and I elided now).

* Karl Berry wrote on Sat, Nov 28, 2009 at 12:06:55AM CET:
> I altered the last example to be about a mistaken upload, instead of
> retiring an existing release.  In general, it seems to me that we don't
> want to suggest that it's a good idea to delete test (or any) releases.
> I also didn't see any purpose to the "--" here, so I removed it.

Erm, the --rmsymlink and --delete options work on all remaining files up
to the net --rmsymlink, --delete, or -- option.  So that -- really needs
to be there.  Or we need to change the semantics of these optinos.

>   0. Upload foobar-1.0.tar.gz to ftp.gnu.org:gnu/foobar
>     gnupload --to ftp.gnu.org:foobar foobar-1.0.tar.gz
> 
> Indeed, just goes to show why simple examples, and testing, are needed :).

Yes.

>     Feel free to propose a patch that makes this more clear.  
> 
> See below for my new text.  If you want a patch instead, that's fine, I
> just thought this would be easier to read.

This is fine.

>     If you know of a painless way to test these options, then I'm all
>     ears.  I'm a big fan of testing all code.
> 
> I know of no easy (or even not so easy) way to test anything related to
> ftp uploads, especially not with hypothetical package names and versions :(.

Well, what about an explicit test package name and directory reserved
for testing uploads and so on?  Is that feasible at all?  Say, the
directory could be 'gnupload-test', and the package names keyed by
the name of the person trying the upload, so that multiple developers
don't get in their way.  Kind of thinking that all GNU developers should
be able to test upload functionality there.

> I think this is one case where you just have to take it
> on faith/inspection and let users report the problems when they actually
> try to instantiate them.

Almost anything can be tested.  It's more of a question whether the work
required to actually make it work exceeds the potential benefits.

Cheers, and thanks,
Ralf

[...]
> 5. Delete oopsbar-0.9.91.tar.gz and upload foobar-0.9.91.tar.gz:
>   gnupload --to alpha.gnu.org:foobar \\
>            --to sources.redhat.com:~ftp/pub/foobar \\
>            --delete oopsbar-0.9.91.tar.gz \\
>            foobar-0.9.91.tar.gz




reply via email to

[Prev in Thread] Current Thread [Next in Thread]