807277 - Update the list of modules currently supported by Fennec

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: Documentation, defect, P1)

Description

[Matteo Ferretti [:zer0] [:matteo]]

We're working to supports Fennec, as results of this effort the list of modules currently supported by Fennec is increased. The documentation should be updated.

Comment 2

[Dave Townsend [:mossop]]

Is the pull request ready for review?

Comment 3

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/704

Pointer to Github pull-request

Comment 4

[Matteo Ferretti [:zer0] [:matteo]]

Now yes: I close the old pull request in favor of a better one, with a comprehensive list of all modules: I assigned the review to Will.

Comment 5

[Will Bamberg [:wbamberg]]

Comment on attachment 696313 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/704

I'm a bit uneasy about the extra machinery needed here, especially all the handcoded HTML, but it does look prettier.

I'm also worried it won't get kept up to date, but let's look at automating it when we have metadata for application compatibility.

There are also some language changes, and some HTML tags not closed, for which I've made specific comments in the PR.

Comment 6

[Matteo Ferretti [:zer0] [:matteo]]

I don't like the all HTML code use here as well, but I didn't find a better way to list all the modules without makes the page unreadable and too long. As you said (and I thought I wrote that as well somewhere), I hope that have module metadata with application's compatibility will give to us the capability to generate this list automatically. There is already a `<ul id="modules-index">` or similar, that is doing something like that.

This is to me something temporary, that is much better for the developers than the poor list we have at the moment.

Comment 7

[Matteo Ferretti [:zer0] [:matteo]]

Will, I updated the pull with the comment you suggest. Shall I create a new attachment, even if the link is the same, or you will use the same to approve / keep rejected?

Comment 8

[Will Bamberg [:wbamberg]]

Thanks for making this changes Matteo.

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #7)
> Will, I updated the pull with the comment you suggest. Shall I create a new
> attachment, even if the link is the same, or you will use the same to
> approve / keep rejected?

I don't think it matters, whichever you prefer.

Comment 9

[Matteo Ferretti [:zer0] [:matteo]]

In that case, I'd like to reuse the same attachment, you can change the status to approve it – or add a comment with the current reject status explained what is still missed.

Thanks, Will!

Comment 10

[[github robot]]

Commits pushed to master at https://github.com/mozilla/addon-sdk

https://github.com/mozilla/addon-sdk/commit/b6ba45304bd9d9fd5b750273b93b30fe15e25a26
Bug 807277 - Update the list of modules currently supported by Fennec

- Added modules' compatibility list on documentation
- Updated css

https://github.com/mozilla/addon-sdk/commit/f8381fd23b05868deef7b90de8a607a1a835038e
Merge pull request #704 from ZER0/mobile-list/807277

Bug 807277 - Update the list of modules currently supported by Fennec

Comment 11

[Will Bamberg [:wbamberg]]

Comment on attachment 696313 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/704

Thanks Matteo!

Comment 12

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Looks like some link isn't working right.

Comment 13

[Matteo Ferretti [:zer0] [:matteo]]

Yeah, I saw this morning: in the branch the content-proxy.md was still there, so all the test was passing, and because it was just deleted in master github didn't said anything about conflict – of course, it's a "runtime conflict".

Comment 14

[Will Bamberg [:wbamberg]]

Exactly. Is there something different we should do to avoid problems like this? When I landed code by applying patches, I'd always test after applying the patch to master but before pushing the updated master, so would have caught something like this. But with a pull request, I generally don't. Should I?

Comment 15

[Dave Townsend [:mossop]]

(In reply to Will Bamberg [:wbamberg] from comment #14)
> Exactly. Is there something different we should do to avoid problems like
> this? When I landed code by applying patches, I'd always test after applying
> the patch to master but before pushing the updated master, so would have
> caught something like this. But with a pull request, I generally don't.
> Should I?

For something that is large and touches a lot of the code it is probably worth it. For other code (like this change in fact) I probably wouldn't bother. The automated tests tell us when something has gone wrong and they caught this error.