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:
Change Proposals for EdinburghRelease Awaiting Merge
Search for topics Proposed for EdinburghRelease that are
waiting for merge to the MAIN branch:
Change Proposals for EdinburghRelease Merged to Main SVN Branch
Search for topics Proposed for EdinburghRelease that have been
MergedToCore or
ImplementedAsExtension:
Release State Summary
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
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
--
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:
- The tests are automatically run for every checkin
- Plugin tests are run as well
- 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
- 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:
- 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.
- PluggableDocumentationArchitecture - if this isn't done with care, then the attempts to make code pluggable will lead to chaos.
- 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.
- 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
--
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