Tags:
development1Add my vote for this tag edinburgh2Add my vote for this tag gateway1Add my vote for this tag create new tag
view all tags

Edinburgh Release

Introduction

Edinburgh Release is the first planned feature release after the refactoring, development restructuring in DakarRelease. The release after that will be the FreetownRelease.

Release Focus

The TWikiMission specifies the overall purpose of the project.

Possible areas for the Edinburgh Release to focus on, in order to help TWiki leap forward:

  • Focus on customer centric features (e.g. features that help our target audience most)
    • Examples: Syncronous edits, OO content access syntax
  • Focus on innovation with compatibility in mind
    • Examples: Generic web services interface, a J2EE/TWiki integration, web based updates of TWiki/Plugins/apps, relational database backend, portlet integration, event triggers
  • Strengthen TWiki as an application platform
    • New features and infrastructure supporting that
    • Restructure Plugins web to be a marketplace for TWiki extensions (for free and for a fee)
  • Specific Targets

Development Restructuring

Before the CoreTeam and TWikiCommunity dives into spec and coding work we should review the Development process, model and tools. See PostDakarDevelopmentModel, DakarDocumentationModelIsBroken, PostDakarTrackingAndDiscussion, OneSvnBranchPerRelease, ProcessForMarketDrivenInnovation.

Edinburgh Release Meetings

Meetings are held in #twiki_edinburgh IRC channel.

Change Proposals

Change Proposals for EdinburghRelease still being worked on

Search for topics that still need work:

Priority Proposal Type State Outstanding Issues #
100 TypeCheckParameters FeatureRequest UnderInvestigation   0
Total: 87 Proposals 8 Issues
  TopicListWithoutWebTopics FeatureRequest NeedsARethink   0
  ExtensionToAttachUrlDirective FeatureRequest UnderInvestigation   0
  AutomaticLinkLabelBasedOnHeading FeatureRequest UnderInvestigation   0
  RenameMainWebToHome FeatureRequest UnderInvestigation   0
  SearchByDate FeatureRequest UnderConstruction   0
  MainTWikiPreferencesNeedsFixing FeatureRequest UnderInvestigation   0
  PopupPageIndexForEditing FeatureRequest UnderInvestigation   0
  UserObjectModel CodeRefactor UnderConstruction   0
  AutomateDefaultPluginBinAccessPermissioning FeatureRequest UnderInvestigation   0
  UnicodeSupport CodeRefactor UnderInvestigation   0
  RenameTheMainWeb FeatureRequest UnderInvestigation   0
  ViewInClientTime FeatureRequest UnderInvestigation   0
  EmailThisPageLink FeatureRequest UnderInvestigation   0
  SetTimezoneInTWikiDotCfg FeatureRequest UnderInvestigation getting correct syntax for your TZ is problematic 1
  CreateNewTopic FeatureRequest UnderInvestigation   0
  RequirementsForMultipleFormSupport FeatureRequest UnderInvestigation   0
  UseCasesInDocumentation DocRequest UnderInvestigation   0
  TopicComponents FeatureRequest UnderInvestigation   0
  ShowLocalTimeOfUser FeatureRequest UnderInvestigation   0
  ProvideAccessToWebMetaData FeatureRequest RejectedProposal Implementation is totally different from proposed spec on this topic. Please document the TWikiFuncEachChangeSince feature. 1
  WordDiff FeatureRequest UnderInvestigation   0
  MoveAttachmentsOutOfPub FeatureRequest UnderInvestigation Define requires for various grades of corporate and non corporate security 1
  AccessControlLists FeatureRequest UnderInvestigation   0
  PerTopicWebNotifyReports FeatureRequest UnderInvestigation   0
  EditOnPreviewPage FeatureRequest UnderInvestigation   0
  ServerUniqueId FeatureRequest UnderInvestigation   0
  LetICONCalculateImageSize FeatureRequest ClosedProposal are all icons that need to be 16x16 actually that size? 1
  GetRidOfTWikiUsersPage FeatureRequest UnderInvestigation   0
  UserSpecifiedRedirect FeatureRequest UnderInvestigation   0
  SimplestPluginIdea FeatureRequest NeedsARethink   0
  ObjectOrientedTWikiPluginSystem FeatureRequest UnderInvestigation   0
  WorkFlow FeatureRequest UnderInvestigation   0
  UpdateAttachmentsDontWorkAsExpected FeatureRequest UnderInvestigation   0
  MainTWikiPreferencesOverridePluginSettings FeatureRequest UnderInvestigation   0
  BetterLists FeatureRequest UnderInvestigation   0
  AvoidRenameLosingHistory FeatureRequest UnderInvestigation   0
  MakeAnchorVariable FeatureRequest UnderInvestigation   0
  TopicRenamedHandler FeatureRequest UnderInvestigation   0
  ShouldNoViewImplyNoEdit FeatureRequest UnderConstruction   0
  MoveSettingsOutOfText FeatureRequest UnderInvestigation   0
  DontShowPreferencesToNonAdmins FeatureRequest UnderInvestigation   0
  AttachTableRowWhenNoAttachments FeatureRequest UnderInvestigation   0
  SkipMinorChanges FeatureRequest UnderInvestigation   0
  ManageStaleContent FeatureRequest UnderInvestigation   0
  GettingTheUsernameWrong DocRequest UnderInvestigation   0
  StoreFacade FeatureRequest UnderInvestigation   0
  ViewContentsofArchiveFileAttachment FeatureRequest NeedsARethink   0
  MetaExpansionImprovements FeatureRequest UnderInvestigation   0
  SomeTWikiVariablesShouldBeInPlugins FeatureRequest UnderInvestigation   0
  SmiliesShouldBeInCore FeatureRequest NeedsARethink   0
  InhibitTopicSelfLinking FeatureRequest UnderInvestigation   0
  HideEditingBarFromUsersThatAreNotAllowedToEdit FeatureRequest NeedsARethink   0
  TWikiInstallerWindows FeatureRequest UnderInvestigation   0
  GracefulFallbackWithPatternAndTwisty FeatureRequest ConsensusReached   0
  PageTitleVariable FeatureRequest RejectedProposal   0
  RegistrationShouldBeFormTemplateDriven FeatureRequest NeedsARethink   0
  NewWindowPerTopic FeatureRequest UnderInvestigation   0
020 HierarchicallyNestedTwikiWebs FeatureRequest UnderInvestigation   0
080 HtmlAnchorsOnRdiffSequentialOutput FeatureRequest UnderInvestigation   0
080 UseLessStepsToReparentATopic FeatureRequest UnderInvestigation   0
080 BetterMore FeatureRequest ConsensusReached Waiting for Main.ArthurClemens 1
085 SuggestSingularNotPlural FeatureRequest NeedsARethink   0
090 ShipMd5Sums FeatureRequest UnderInvestigation   0
100 InvisibleMultipleExclamationMarksInHeader FeatureRequest UnderInvestigation   0
100 DiffsShouldShowEntireTableRow BugReport ConsensusReached Waiting for Main.SvenDowideit 1
100 ImportingExternalDataToTWiki FeatureRequest UnderInvestigation   0
100 EditTablerowPluginAsDefaultPlugin FeatureRequest UnderInvestigation   0
100 JumpBoxSlowInLargeWebs FeatureRequest UnderInvestigation   0
100 AddToMyLinks FeatureRequest UnderInvestigation   0
100 EnhanceAuthMethods CodeRefactor UnderInvestigation   0
100 WikiNameHighlighting FeatureRequest UnderConstruction Unchecked for performance and compatibility 1
100 FormattedSearchCountVariable FeatureRequest UnderInvestigation   0
100 AnchorToolTipSummary FeatureRequest UnderInvestigation   0
100 FormattedSearchSectionVariable FeatureRequest UnderInvestigation   0
100 PreviewOnEditPage FeatureRequest UnderConstruction   0
100 FootnotesFeature FeatureRequest UnderInvestigation   0
100 PersonalizedRss FeatureRequest UnderInvestigation   0
100 DocumentedDefaultParameterValuesForInclude FeatureRequest UnderInvestigation
  1. Agree on feature
  2. Agree on spec for syntax
  3. Apply patch
  4. review code
  5. test
  6. Put documentation into place.
1
100 AddWorkareaFunctions FeatureRequest UnderInvestigation   0
100 SearchOrderAndLimitBehavour FeatureRequest UnderInvestigation   0
100 AttachmentCount FeatureRequest UnderInvestigation   0
100 MultipleEditsOnSamePage FeatureRequest UnderInvestigation   0
100 ConsolidateSkinTemplates CodeRefactor UnderInvestigation   0
100 RegistrationShouldNotBeInTheTWikiWeb FeatureRequest UnderInvestigation   0
100 CentraliseTopicProcessingHeuristic CodeRefactor UnderInvestigation   0
100 PluginsShouldRegisterSymbols FeatureRequest UnderInvestigation   0

Change Proposals for EdinburghRelease Awaiting Merge

Search for topics Proposed for EdinburghRelease that are waiting for merge to the MAIN branch:

Priority Proposal Summary Outstanding Issues #
100 SearchByCreateDate Enhance SEARCH to allow searching by create date   0
Total: 3 Proposals 0 Issues
  MetaParentShouldUseMinimalMatch     0
  INCLUDEurlDoesNotWorkWithSSL This topic ended with a patch to support https-INLCUDE's   0

Change Proposals for EdinburghRelease Merged to Main SVN Branch

Search for topics Proposed for EdinburghRelease that have been MergedToCore or ImplementedAsExtension:

Proposal Summary Outstanding Issues #
ShowOutgoingLinksWithSymbol Show outgoing links with a symbol   0
Total: 19 Proposals 1 Issues
AddFormatToMeta Add format parameter to META and METASEARCH   0
AddGetSessionKeysToFunc Get a hash of all the names of session variables   0
AlternatePluginTagHandling Alternate mechanism for plugins to handle tags   0
AutoIncTopicNameOnSave Create Auto-incrementing Topic Names   0
CleanUpTWikiVariables Clean up the docs in TWiki.TWikiVariables   0
CopyPreviousRevisionTopicContentIntoNewRevision Improved UI for copying topic content incl meta into new revision Bugs:Item1966 1
CustomizableNewWikiWordLink Add preference value to customize the new-wikiword link   0
DeprecateTWikiFuncGetOopsUrl Deprecate TWiki Func getOopsUrl   0
ExpandStandardEscapes Add function decodeFormatTokens to decode format tokens to TWiki::Func   0
MergeExtendedSelectPluginToCore     0
NewTopicTemplate     0
OrganizeTWikiVariables Extend what has been begun with splitting TWikiVariables by adding more variables   0
PassCustomVariablesWhenCreatingANewWeb Let createweb script add custom variables to WebPreferences of the new web.   0
PassMetaToHandlers New parameters in handlers to support permission checking   0
PluginHandlerForContentMove Add Rename Handler for Plugins   0
ProposalToEnableRenamingTopics Topics must be renameable without users losing track of content.   0
ProposedChangeToWikiWordSpec Proposal to change Wiki Word syntax   0
RefactorUsersCode Refactor user management to eliminate user object and inefficiencies   0

Release State Summary

Change Proposal State Proposals Issues
Still being worked on 87 8
Awaiting Merge 3 0
Merged to Main SVN Branch 19 1
Total 109 9

See also EdinburghReleaseSummary and EdinburghReleaseUpgradeGuide

There are lots and lots of other ideas floating around; see ThingsToDo. You may not see your favourite idea above because no-one has expressed and intention to do it for EdinburghRelease. Go and visit ThingsToDo and FreetownRelease and help set priorities for all those things that are still to do. Please be aware that contribution of the code in a readily incorporatable patch format is most likely to be included in the core.

Old Feature Requests not in Codev web

Item: Owner: Spec: Impl: Docs: Patch Integrated Into TWiki CVS: Int Tested
Support.SettingCorrectTimeZone ? 100% 100% 0% 0%  
Plugins.MultiSearchAddonDev Main. 0% 0% 0% 0%  
Support.ProblemWithAnchorLinks Main. 0% 0% 0% 0%  

Known issues

Feedback and requests

I've changed the tables in ReleaseFeatureTable to put anything without AssignedToCore in the a nice to have table so that they can be automated. It seems pretty logical from reading ScheduledFor and AssignedToCore.

This has lost the Patch Integrated Into TWiki CVS and Int Tested columns. If these were useful then they will need to be included in the WebForm. If so follow disscution should take place in RestructureCodevWorkFlow or PostCairoDevelopmentModel.

The manual "Nice to Have" table will be removed once all the topics listed in it have been ScheduledFor this release.

-- SamHasler - 07 Sep 2004

Ok, reassigned everything that was in this web. Not sure what to do with the last 4 items.

-- SamHasler - 08 Sep 2004

some important topics to hit on on the next release, IMHO:

  • skins development and consolidation
  • topic object model
  • event triggers
  • gui improvements (AJAX)
  • gui improvements (elision)
  • scalability
  • syndication
  • plugin component system
  • twiki application bundling (and I18N bundling)
  • wiki patterns cookbook (and/or explanations of wiki patterns used throughout the system docs and/or twiki.org)
  • storage plugin
  • revision control plugin
  • branching/merging/milestoning
  • visualisation

please, add your list

-- WillNorris - 09 Oct 2005

A number of things that spring into mind:

  • relax wikiword syntax (f.i. freeform linking or TopicDisplayName)
  • secure attachments (making attachments optionally secure, not in /pub)
  • skin development = (better) base templates; further consolidation not necessary IMO)
  • topic parts in tabs (ala Wikipedia: documentation / discussion)
  • better tabs (a few examples have been shown around here)
  • internationalized messages for every language (FOR EACH language ... write message)
  • indexing for faster searches
  • improve topic findability for Google
  • better navigation: for instance with tags, classification, etc

-- ArthurClemens - 05 Feb 2006

My list is on my PersonalRoadmap... we need to agree where features go... In a web like Bugs for feature requests, on personal roadmaps on a single page or a set of form driven stuff. Whatever. We just need to agree.

-- MartinCleaver - 06 Feb 2006

Better to list them at one central place. That way everything can be found, duplicates eliminated and it forces people to rething/update their roadmaps.

-- ArthurClemens - 06 Feb 2006

I'm guessing thats why Crawford suggested we use the Bugs web, and maybe we rename it to a tasks web smile

-- SvenDowideit - 06 Feb 2006

Each release needs a focus, Dakar had a big refactoring focus initiated by Crawford. The release focus is a guideline that helps people work on a common goal. It does not mean that developers cannot implement their favorite toy.

So, for Edinburgh, we need to agree on an overall focus. As a start I created a focus on top.

Besides this, I think we can improve how we operate:

-- PeterThoeny - 06 Feb 2006

Lets not forget performance. As Kenneth keeps pointing out, degrading performance will not make up for additional features. All these features cost code and as Crawford points out its the compile time that dominates performance.

-- AntonAylward - 07 Feb 2006

May I suggest add a point on "Requirement Management" in the next meeting? I whould really want to sort out how to manage the "work in process" and how to relate the Bugs web with Codev.

-- RafaelAlvarez - 07 Feb 2006

now that there are a couple of pluggable implementations of core functionality (HTPasswd, RcsStore, TemplateLogin, and soon TWikiUserMapping) I'd like to change the mechanism we use to do this, to allow Plugins to tell configure that they are an implementation class for one (or more) of these interfaces, and thus allow the use to select the implementation they want from there.

essentially this would make TWikiCore an over-rideable set of base implementations, which plugins would either be able to totally replace, or extend through the perl object model.

for eg

unlike cgiwiki and kwiki, we would not be forcing users that want to try out an implementation module to write (admittedly trivial) code, they just install the plugin, and use the configure script.

More info in ObjectOrientedTWikiPluginSystem

development process idea

I'd like to put forward the idea (not fully formed) that we use Codev to discuss Ideas, wheres the Bugs system continues to be used to identify actions. In this way, Codev discussions could continue over the span of multiple releases - rather than being assigned to a release as now - with actioned release specific items being refered to from the Bugs system. This could help reduce the backwater topics we have in codev, who's titles suggest a generic concpet, but who's text refer to the implementation at a particular time.

-- SvenDowideit - 15 Feb 2006

I would add, put in the Codev topic all the related items in Bugs so it's easy to keep track of actions.

-- RafaelAlvarez - 15 Feb 2006

Like I tried to do after Cairo release, I'd like again to have a feature freeze, and some committed development of test infrastructure, unit tests and testcases. Far to many fixes have gone in without testcases, and TML is only 1/4 tested at best. IMHO you shouldn't even even think about adding new features until:

  1. The tests are automatically run for every checkin
  2. Plugin tests are run as well
  3. TML unit tests are in place
If the tests are too hard to run, then put some effort into making them easier. Every time someone adds a feature, they risk breaking some existing functionality. The only way to control that is to ensure that all functionality is tested to spec.

-- CrawfordCurrie - 20 Feb 2006

i've started to bring back the tinderbox (Bugs:Item1684), but eventually we will run into the lack of hardware on *.twiki.org (Bugs:Item289). what can we do about that now that the DakarRelease is out?

-- WillNorris - 20 Feb 2006

It has been mentioned that performance suffers due to compatibility constraints (TWikiMission: Protect corporate investment (topic contents) from data corruption and incompatible changes - don't require the use of upgrade scripts (e.g. category to forms upgrade happened automatically)). Would it be possible to make "Dakar and earlier compatibility" a configurable option?

-- ArthurClemens - 21 Feb 2006

During EdinburghReleaseMeeting2006x02x20 i offered to try and move forward the discussion regarding priorities for EdinburghRelease. Didn't get as far as I wanted in terms of figuring way to poll priority among the ideas from brainstorming. However, i was able to group the ideas under 5 top areas and thought i'd put this back out for consideration.

Here we are:

  • Strengthen TWiki as an application platform
    • CMS
    • modularity
    • Relax wikiword syntax
  • Simplify
    • Installation
    • Syntax
    • Documentation
  • Improve Usability
    • GUI
    • Wysiwyg
    • AJAX
    • Improve documentation
  • Performance/Scalability
    • Mod_perl
    • Indexing
    • Caching
  • Security
    • secure attachments
  • Marketing
    • Focus on features that help target audiance
    • Improvements to TWiki.org

-- LynnwoodBrown - 27 Feb 2006

If I didn't miss something, then the last Edinburgh Release Meetings didn't discuss much Edinburgh Release - so I guess there's still enough time to settle priorities.

Here are my personal favourites:

  1. TWiki performance: There have been a couple of ideas around, and even more wild guesses. I feel we need to do lots of the tedious stuff (profiling, benchmarking, measuring, analyzing) to make considerable progress.
  2. PluggableDocumentationArchitecture - if this isn't done with care, then the attempts to make code pluggable will lead to chaos.
  3. Simpler installation and site management: Same reason as above. If modularization keeps going, every installation will be different. This will make answering Support questions difficult unless there are some utilities around to dump (or sanitize) a particular installation.
  4. User management (SvenDowideit has started on that) - DakarRelease brought progress with respect of modularization, but there's a conflict between e.g. customisation of registration and upgrades (which bring new versions of all the registration related topics)

-- HaraldJoerg - 19 Apr 2006

Is there a targetted release date? Even a a simple year if there isn't enough info to pin down a month would be nice.

-- EricHanson - 27 Apr 2006

On past performances, it could be as long as a year. On the other hand, we would like to be generating minor increments to 4.0 in the interim. So we may just generate 4.x releases, and then suddenly one day start calling it 5.0 smile

-- CrawfordCurrie - 28 Apr 2006

I've re-enable the inclusion of ReleaseQueuesInsert. It doesn't appear to be too slow now. And I've converted all the old WebForm topics to ChangeProposalForm.

-- SamHasler - 29 Apr 2006

Edit | Attach | Watch | Print version | History: r38 < r37 < r36 < r35 < r34 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r38 - 2007-01-09 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.