Re: [yaco-idsubmit-tool] Testing notes / Henrik / March 11

[Henrik Levkowetz <[e-mail]>]

Hi Emilio,

On 2011-03-12 18:34 "Emilio A. Sánchez López" said the following:
>     Hi Henrik,
> 
> El 11/03/11 18:09, Henrik Levkowetz escribió:
>>
>> Testing issue:
>>
>>    * I'm not seeing any posting confirmation emails going out to the
>>      testing address, which makes it impossible for me to carry through
>>      the testing to a final post, and verify that the document is online.
> 
>     The testing address is redefined in the settings_local of beta using 
> EMAIL_COPY_TO so I can have access to the emails. I can revert to the 
> original configuration or better add the two email addresses.

Yes, please; that would make testing all the way through to posted document
possible.

>> Bugs:
>>
>>    * Failed idnits run on second submission?  I did one upload of
>>      draft-ietf-dnsext-axfr-clarify-16.txt, which had some metadata
>>      flaws, fixed those and uploaded again.  The (failed) idnits results
>>      from the second upload is incomplete, showing only this:
>>
>> 	"idnits 2.12.07
>>
>> 	/var/www/staging/draft-ietf-dnsext-axfr-clarify-07.txt:"
>>
>>      Running idnits 2.12.07 locally on the draft produces the expected
>>      output.
> 
>     Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/611

Thanks.

>>    * Abstract extraction.  Processing draft-ietf-dnsext-axfr-clarify-16.txt
>>      gives an abstract which includes the first 2 paragraphs from the
>>      Introduction section.  You should probably add a condition which cuts
>>      the abstract when a line matching "^ *[0-9]+\.? " is found, to stop at
>>      the first numbered section.
> 
>     The only problem with this regular expression is that some drafts 
> contain lines beginning with a number, an optional dot and a space like in:
> 
>     http://tools.ietf.org/id/draft-ietf-dnsop-default-local-zones-14.txt
>     http://tools.ietf.org/id/draft-ietf-hokey-ldn-discovery-06.txt

Ah.  Right.

>     But it works pretty well if we check that the previous line was a 
> blank line.

Right.  Very good.

>>    * Abstract extraction (II).  Processing draft-eastlake-sha2b-05 results
>>      in an abstract which is cut short.  The last line of the first paragraph,
>>      and the entire second paragraph of the abstract is missing.
> 
>     I have extended the abstract extraction to fix that bug and the 
> previous one at http://wiki.tools.ietf.org/tools/ietfdb/ticket/612

Thanks.

>> Flaws:
>>
>>    * It's unnecessarily hard to upload a fixed version of a draft after
>>      flaws has been found in a first upload.  You have to either remember
>>      to cancel on the check page, or follow the link provided to go back
>>      and do it later.  I'd prefer that for a failed upload (idnits or
>>      meta-data failures) a new upload would automatically cancel the
>>      previous one; at least a new upload from the same IP address.
>>
>>    * Also, cancelling a submission with idnits or meta-data errors should
>>      not cause an 'Are You Sure' dialog.
> 
>     Added at http://wiki.tools.ietf.org/tools/ietfdb/ticket/613



>>    * When the draft name found in the text of an uploaded draft contains
>>      characters which are not permitted, there's an error message next to
>>      the upload filename box.  This can be misleading, especially if the
>>      filename of the upload doesn't violate the rule.  Please change the
>>      message "Filename contains non alpha-numeric character: %s" next to
>>      the upload filename box to be a metadata error on the check page,
>>      and change the text to something like "The draft name found in the
>>      document, '%s', contains one or more alphanumeric characters: '%s'."
> 
>     That error is a critical error (critical errors are the ones that do 
> not allow to reach the status page). If some extrange caracters apear in 
> the draft name then draft.py is unable to extract name and revision. 
> Also the draft name is used as filename to the files when saved into the 
> stagin area so it's a bad idea if the have non alpha characters.
> 
>     In the old tool this one was also a critical error that doesn't 
> allow to proceed to status page. Do you really need to reach the status 
> page in these cases? Maybe will be enough if we change the error message.

I understand your reasoning, and if the draft can't be saved in the staging
area you shouldn't really go on to the check page.  However, the error message
needs to be different, as you say; and I also think it shouldn't be presented
as an error related to the upload form entry -- that gave me the impression that
the upload hadn't succeeded.  Better make it an error message presented just
above the set of upload form entries, and say that the upload succeeded, but
the file could not be saved in the staging area because <reason>, where <reason>
could be that no document filename was found in the document, or that the
document filename found contained disallowed characters, or ...

>>    * On at least one occasion, (draft-ietf-v6ops-ipv6-cpe-router-08.txt),
>>      the first time I clicked the 'Post' button I was just returned to the
>>      same page.  A second click on 'Post' resulted in the submitter auth
>>      page.
> 
>     It's a reproducible bug, that is good.
> 
>     Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/613

Thanks.

>> Nits:
>>
>>    * On the check page, there's initially a large blank area above the
>>      Meta-Data area, which then (as the style sheet is read in??) reduces
>>      to a reasonable height.  Please make this appear the same from the
>>      start.  If this is caused by the idnits page element, you could maybe
>>      take it out of the regular html placement flow by giving it absolute
>>      placement from the start?  (Just guessing here as to the cause...)
> 
>     Wow, you have a fast eye. I had to try with different browsers until 
> I see this behavior.

Longer load time at a distance is more likely the reason, I think :-)

>     Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/615

Thanks.

>>    * If a draft name is found in multiple places on the first page, it would
>>      make it easier to correct for instance a bad revision number if the
>>      meta-data error message would quote the full line where the bad rev.
>>      number was found.
> 
> 
>     I have decorated the two pages dialog so it highlights the draft 
> name that contains the error. I think this way is fast and more graphical.
> 
>     See at http://wiki.tools.ietf.org/tools/ietfdb/ticket/616

Excellent.  Thanks.

>> The notes above is what I have from testing 8 drafts which have been
>> troublesome in the past.  As soon as the first bug is fixed, so it's
>> possible to do repeat submissions with idnits fixes, I'll test more.
> 
>     I have applied all the fixes and added the original testing email 
> address to settings_local in the beta server.

Splendid!  Thanks.


Best regards,

	Henrik