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

["Emilio A. Sánchez López" <[e-mail]>]

    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.

> 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

>    * 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

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

>    * 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

> 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.

>    * 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

> 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.

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

>    * 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


> 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.

    Best,

>
> Best,
>
> 	Henrik
> _______________________________________________
> yaco-idsubmit-tool mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yaco-idsubmit-tool


-- 
Emilio A. Sánchez
[e-mail]