[Typo3-dev] System Extensions, part II

Kasper Skårhøj kasper2004 at typo3.com
Tue Nov 16 15:42:09 CET 2004


Sorry, the URL to the current selection of global extensions is:


http://130.228.0.33/t3dl/src/global_extensions_for_3.8.0.tgz


On Tue, 2004-11-16 at 15:41, Kasper Skårhøj wrote:
> Hi Folks,
> 
> 
> Maybe you remember I send a mail in May about how many of the current
> global extension will move to the sysext/ (System Extensions) folder. I
> also attached a document which outlined the principles behind including
> a list of actions I wanted to take and an invitation to comments. AFAIR
> only a few responded so I now just did what pleased me best.
> 
> So here is the overview. From the next version of TYPO3 you will find
> these extensions in the sysext/ folder:
> 
> aboutmodules
> belog
> beuser
> cms
> context_help
> css_styled_content
> extra_page_cm_options
> func_wizards
> impexp
> indexed_search
> info_pagetsconfig
> install
> lang
> lowlevel
> setup
> sv
> sys_action
> sys_note
> taskcenter
> tsconfig_help
> version
> viewpage
> wizard_crpages
> wizard_sortpages
> 
> 
> 
> The ext/ folder (global extensions) will be empty from now on and you
> can put your own extensions in there which you will have to manually
> update from TER when needed. Probably we will distribute the global
> extensions one last time with the next version as a service to you so
> you will have an easy upgrade of TYPO3. The remaining global extensions
> are:
> 
> cms_plaintext_import
> conf_userts
> direct_mail
> direct_mail_subscription
> extrep_wizard
> feuser_admin
> freesite
> imagelist
> kickstarter
> metatags
> phpmyadmin
> plugin_mgm
> quickhelp
> rte
> rte_conf
> setoldpluginlist
> skin1
> static_file_edit
> sys_messages
> sys_notepad
> sys_stat
> sys_todos
> sys_workflows
> taskcenter_modules
> taskcenter_recent
> taskcenter_rootlist
> tipafriend
> ts_language_de
> ts_language_dk
> ts_language_fr
> ts_language_nl
> ts_language_no
> tstemplate
> tstemplate_analyzer
> tstemplate_ceditor
> tstemplate_info
> tstemplate_objbrowser
> tstemplate_styler
> tt_address
> tt_board
> tt_calender
> tt_guest
> tt_news
> tt_poll
> tt_products
> tt_rating
> 
> For people updating the core from CVS later today you should grab this
> TAR ball: 
> 
> 
> 
> BACKGROUND.
> This is a copy/paste from the document I send to the list in May if any
> of you want to study the background for this change and the principles I
> believe should guide our selection of system extensions:
> 
> <snip>
> 
> 
> In the debate about TYPO3 version numbering, separation of core and
> extensions and marketing of TYPO3 as a whole, we finally worded what we
> are already doing by favouring certain extensions in the distribution
> (like the global extensions): "System extensions"
> 
> "System extensions" is a word for the extensions that are considered
> cornerstones in TYPO3 and the features of which are officially promoted
> as something the system includes. This proposal is a suggestion for how
> we can technically underline this approach in the future.
> 
> We will:
> 
>       * Remove *all* global extensions in the distribution (some of
>         which will become "System extensions", see below)
>         
>       * Select all extensions that are now considered "System
>         extensions" and include in the core folder "typo3/sysext/".
>         
>         
> 
> 
> Pros:
> 
>       * Quality assurance: System extensions will represent "cream of
>         the crop" of extensions, both in quality and general usefulness.
>         
>       * Wholeness: TYPO3 comprised of a) core and b) system extensions
>         can better be understood as a whole. The feature list will
>         reflect the combined features of core and system extensions.
>         This is also what is marketed/communicated outwards. They also
>         share branching/tagging for releases in CVS which in again
>         reinforces the concept of a whole.
>         
>       * Larger "Core" team: The "Core developers" list will naturally
>         include all authors of system extensions. These people will have
>         access to core CVS (although initially restricted to their
>         extension workspace). This might also make it more natural to
>         recruit people into working on other parts of the core! Finally,
>         the "one-man-show-fear" people have will hopefully be
>         diminished, not because I loosen grip but because it becomes
>         evident that system extensions is a part of the core and slowly
>         is becoming the larger part of the system. Yet, we don't loose
>         the advantages of having clearly identified working areas (each
>         system extension) for the various core developers.
>         
>       * Easier CVS usage: We avoid the illogical situation that current
>         global extensions that many consider part of "the core" are not
>         in the Core CVS repository. They *will* be in Core CVS as
>         "system" extensions (like "cms" and "lang"). We don't solve the
>         symlink redundancy problem though.
>         
>       * Easier updates for the "whole system": Before, people had to
>         keep track of updating both core AND sometimes system
>         extensions. Now, they don't have to think about that anymore,
>         just update the core and all system extensions will
>         automatically follow.
>         
>       * Global extension space free for use: With an empty global
>         extension space people can fully utilize this for their own
>         installed extensions. Before this was a big problem because in
>         reality the global extensions was distributed with the core just
>         as much as the system extensions was. So in this new situation
>         peopel can freely choose "global" or "local" install based on
>         their preference without any (or much fewer) drawbacks related
>         to upgrades.
>         
>         
> 
> 
> Cons:
> 
>       * The size of the core will grow with the size of the new system
>         extensions (but of course fall with the size of abandoned global
>         extensions). Maybe that is not a problem.
>         
>       * The PHP developers experienced that having many extensions
>         distributed with the core made it hard to manage that all
>         contributers finished on time. So: We might face problems
>         getting new releases out when someone did not deliver what they
>         promised. But we can also introduce principles to solve this.
>         One could be two-person maintainer ship. Another is the
>         principle that if someone did not finish his work in time, we
>         just take the old version from previous release.
>         
>         
> 
> 
> Transitional phase:
> 
> The transistion will be easy. First release of this structure will
> simply ship all global extensions that were not promoted to system
> extensions (thus all extensions that came along in previous release are
> still there, just some switched position). However this will be the last
> time that happens - from that point the global extensions is a local
> matter how people organize them and the system in general will not
> impose any requirements on them.
> 
> 
> Qualifying as System Extensions
> This is the topic where we need some debate on the dev-list.
> 
> 
> 
> I think we should select the new collection of system extensions based
> on two major criterias:
> 
>       * Feature coverage: That is when an extension (uniquely?) offers
>         an announced feature of TYPO3. Examples are DAM, DBAL, RTE,
>         RealUrl etc. Some types like "Guestbook" does not apply since
>         many of them might exist and are low-complex.
>         
>         (A nice sideeffect of looking at it this way is that it will be
>         clear what areas of features are not yet covered by TYPO3!)
>         
>       * Popularity: That is extensions which are so widely used by the
>         community that it makes good sense to include it for convenience
>         reasons. We might also assume that this is a sign of good
>         quality. Examples are: Auto Make Template, Template Selector,
>         Gallery etc. (see popular list on TYPO3.org)
>         
>         
> 
> 
> Another set of criterias could be (and supplements the above):
> 
>       * Either so simple that no one would make an alternative
>         
>       * Or so complex that a single one should do it all
>         
>       * Never extensions where many flavors would select different
>         approaches anyways!
>         
>         
> 
> 
> Finally there are overall requirements to extensions:
> 
>       * Size: The extension must not be bloated in size (phpMyAdmin
>         fails this test for example, being 2 MB or more).
>         
>       * Author: The author must be committed to maintenance and
>         participate regularly as a core developer.
>         
>       * Documentation: Adequate documentation accomplished
>         
>       * CGL: Adheres to TYPO3 coding guidelines
>         
>       * Review: Can qualify for a "cigar" rating in a review.
>         
>       * Dual-maintainer: [Idea] At least two people are involved in the
>         development, each having access to the CVS of the extension and
>         authority to carry out changes (to avoid dependencies on a
>         single author).
>         
>       * Goals: The extension must have a Todo list and the author/team
>         behind must announce goals (if any) to achieve for each planned
>         release of the core.
>         
>         
> 
> Selecing the new System Extensions
> Next step is practical: To select which extensions will be promoted as
> system extensions. This will include a look at a) the current global
> extensions and b) the TER.
> 
> 
> 
> Global extensions:
> 
> In this table you will find all current global extensions listed. This
> is an explanation of the columns:
> 
>       * Extension Key / Title: Obvious
>         
>       * New status: Indicates the suggested new state (this is up for
>         debate!): 
>         
>               * "enable" / "include" : Means the extension is promoted
>                 to become a system extension and if set to "enable" it
>                 will be installed by default.
>                 
>               * "-" : Means the extension will NOT be a system extension
>                 and has to be installed separately.
>                 
>                 
>       * Pkg (package): [new concept] For extensions that are not system
>         extensions anymore we thought it might make sense to define
>         packages of extensions for various purposes. For instance there
>         will be a collection of extensions which are typically useful
>         for developers - they will be in a package and they can be
>         installed / upgraded in one click. Technically this means we
>         need to extend support in the extension manager so more
>         extensions can be installed/upgraded in one go.
>         
>       * Cur (Current status): "S" means "Shy" extension - basically it
>         indicates that this extension is currently one of those loaded
>         by default in blank installations. "I" means "Internal" which
>         means the extension is somehow favored by the system in a
>         hardcoded way.
>         
>       * Needs: Sums up if there are any development plans for this
>         extension or some other needs for it.
>         
>       * Maintainers: This tells who will be maintaining the system
>         extension. In most cases there is a "?" sign and that means we
>         need someone (2 people at least) to take over maintenance!
>         Please volunteer!
>         
>         
> 
> </snap>
> 
> 
> Finally, I have listed some suggestions to candidates that might go into
> the sysext/ folder as well, all extensions which are currently not
> global.
> 
> Please comment on this and suggest others if you think they fit the
> criterias given above.
> 
> 
> 
> 
> 
>            Extension Key
> 
>                Reason
> 
> templavoila
> 
> Popular
> 
> Unique feature
> 
> automaketemplate
> 
> Popular
> 
> dbal
> 
> Cornerstone feature
> 
> dam
> 
> Unique feature
> 
> rlmp_officedisplay
> 
> Unique feature, but specific
> 
> realurl
> 
> Unique feature
> 
> rtehtmlarea
> 
> Unique feature, democracy (Offers
> RTE available for both Linux and
> Windows)
> 
> NOTE: May be one of the other
> HTMLArea based RTEs instead! We will
> select the best.
> 
> newloginbox
> 
> Popular
> 
> awstat
> 
> Popular
> 
> rlmp_tmplselector
> 
> Popular
> 
> de_phpot
> 
> Popular
> 
> 
> 
> 
> 
> 
-- 
- kasper

--------
Please notice NEW EMAIL ADDRESS for 2004!! (due to SPAM-contamination)
	
"kasper2004 at typo3.com"





More information about the TYPO3-dev mailing list