[ckan-dev] [#2477] Add extensions section to docs

[Irina Bolychevsky]

This all sounds good to me. When are people planning to go through the
extensions? I can help and give my perspective about where the various
functionality fits in in terms of product lines.

Cheers,
Ira

On 8 June 2012 18:34, Sean Hammond <sean.hammond at okfn.org> wrote:

> Hey all, this ticket asks for a central, up to date list of supported
> extensions and their docs to be created. Something to decide in a
> standup next week. Right now we have a list of extensions in the docs:
>
> http://docs.ckan.org/en/ckan-1.7/extensions.html#choosing-extensions
>
> and that also links to another list on the wiki:
>
> http://wiki.ckan.org/List_of_Extensions
>
> It looks like neither have been updated for a while, so I guess we need
> to go through and update them. I'm happy to take on trialling the
> extensions and updating the docs but it'd be good to quickly run through
> together to get opinions on what should be maintained and what isn't
> worth it anymore.
>
> I think we want to have three groups of extensions:
>
> 1. Core extensions that are maintained as part of the CKAN code base. We
> commit to keeping these working as we develop CKAN, if we don't want to
> keep one up to date anymore we move it out of core.  Each one should be
> documented in its own section in the CKAN docs. I think it'd be good to
> make this list of extensions more prominent in the docs, e.g. a 'Core
> Extensions' chapter with a section for each extension, that appears in
> the main list of contents. They should all have tests too.
>
> 2. Officially supported extensions that are not in core, e.g. because they
> have big dependencies that we don't want in core.
>
> We still commit to keeping these working and they should have tests that
> we run, e.g.  before merging a big branch into core or before a release.
> Consider trying to get jenkins to run the tests for them.
>
> Could we still keep the code for these in the core CKAN git repo, but
> give each extension its own requirements file that you only run if you
> want to use that extension?
>
> If we do keep the code in core then I'd suggest documenting them in the
> core docs like the other extensions. If not, we just do what we're doing
> currently, which is to keep a list of links to them in the core docs,
> and each extension just has a README.rst file in its git repo.
>
> 3. Other extensions, not officially supported.
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>



-- 
Irina Bolychevsky
CKAN Product Owner

The Open Knowledge Foundation (http://www.okfn.org)
Our community data hub: http://thedatahub.org/
More information on CKAN: http://ckan.org/

Follow me on Twitter: http://twitter.com/shevski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120618/9a4a3f64/attachment-0001.html>