---On 2008.May.30 01:27 PM, Douglas E. Warner wrote:
> alta88[nntp] wrote:
>> i'm having trouble getting MoreLayoutsforThunderbird released to the
>> next version. it's listed as No Extension, so there must be some
>> error somewhere - where can one look? it has a .xpi extension,
>> version has gone to 2.0pre (for Tb3.0pre), min/max Tb is 3.0a1 to
>> 3.0.* and i've added updateInfoURL.
>
> Right now these errors aren't logged anywhere. Bringing it up here is
> fine.
>
> There was a problem yesterday that caused new files not to be parsed
> properly. The problem has been fixed and files added since yesterday
> have been re-parsed. Let me know if it still doesn't show up properly.
yes it eventually showed up in the Extensions list and was
workable.
>
>> in general, it feels clunky using File Management.
>> 1.if i already have an updateInfoURL in the install.rdf, then on click
>> of the url link it should show it in the dialog.
>
> The em:updateInfoUrl isn't supported in install.rdf according to the
> documentation on dev-mo [1]; if you have documentation that shows
> otherwise I'd be glad to support it.
>
>> if i cancel, it shouldn't say 'saved'. did i save a blank?
>
> I can't reproduce this; would you mind checking again?
>
this happened when the xpi was in the No Extensions list. when
it's in the Extensions list, it works fine, displaying the
existing value if there is one and cancels properly.
>> 2.if there's any parsing error etc. that fails the extension it has to
>> be displayed.
>
> I assume you mean when the extension is uploaded and fails to be parsed?
>
> Right now the script that's responsible for parsing .xpi files doesn't
> display any errors when the install.rdf can't be parsed as the only
> place they would be displayed is in the CVS client. It might make sense
> to log so we can display them in the file management tool beside the
> file.
yes, exactly. perhaps have a column that indicates
upload/parse success/failure, with a link to the log.
currently, a fail shows up as No Extension, with nothing else
to indicate reason.
seems like 'thing happen' not infrequently. not a huge biggie,
but errors must be made known. logging and error handling is
a small thing, but saves vast quantities of debugging time.
thanks.
>
>> 3.if an install.rdf contains an entry for updateURL pointing to a
>> valid update.rdf, then perhaps a column can state that. only then
>> would one need to Generate an update.rdf url..
>
> Are you asking for validation of an extension's update.rdf, or just
> checking that the file exists, or that it's pointing at the correct
> mozdev.org generated file?
>
all of the above; if the entry for updateURL exists in
install.rdf, check if the location/file exists. only if not,
indicate the Generate link. otherwise the link mostly won't
be shown; being slow i thought it needed to be done each time..
> Right now we're generating an update.rdf regardless and the project
> owner can choose to include it in their install.rdf. The link to
> generate the update.rdf URL from an install.rdf is to allow developers
> with new extensions get the URL to their mozdev.org-generated update.rdf
> before they package their extension.
>
> Thanks for the ideas and criticisms. Let us know if there's anything
> else we can do to improve these tools.
>
> -Doug
>
> [1] http://developer.mozilla.org/en/docs/install.rdf
>
_______________________________________________
Project_owners mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/project_owners
