Change Proposals for TWiki 4.1

FEATURE FREEZE for 4.1

Per decision at EdinburghReleaseMeeting2006x10x30 we have declared FEATURE FREEZE for TWiki 4.1

• No additional feature proposals are accepted added to this topic.
• New feature proposals can still be added as topics on Codev. You can add your topic to the list on TWikiFeature04x02
• Topics that are already on this topic needs to be discussed and accepted or rejected within the next 14 days. Otherwise they will be deferred to 4.2.
• The 14 day auto acceptance rule is suspended until TWiki 4.1 is released (expected to be in beginning of December).

This decision was made to allow all developers to focus on getting the last new features coded, and the many open bug reports closed. The TWikiRelease04x01Process has been a success and will continue for release 4.2. But the next 5-6 weeks we need to focus ours and your energy on fixing bugs and getting a nice stable 4.1 released before we all get too busy with xmas and new year. We are sure all will understand this.

Manual Progress Tracking of TWiki 4.1 Features

The following proposals are active against 4.1. As per the TWikiRelease04x01Process, when a proposal has been agreed please open a tracking item in the Bugs web and link it from here.

Note to developers: Until we have the ChangeProposals ready for the new TWikiRelease04x01Process, please list suggested change proposals here in this topic.

Bugs:ReleaseNotes?type=minor lists what features are currently marked as releasable for next minor release in the DEVELOP codebase.

When you add a proposal you must

• Propose something that you are prepared to implement yourself or with an already committed developer.
• Create a new topic describing your proposal. You can use the WebCreateNewTopic (Submit new feature request form).
• Add the new topic to the bottom of the "Proposals with their own supporting topic" section.
• Do not discuss the proposals here. Discuss them in the individual proposal topics. KennethLavrsen and SteffenPoulsen in the roles of Customer Advocates maintain short one liner status messages. If you update the status feel free to alter the current status but do not discuss the topics here.
• You can add one-liners under "Ideas" but they are not considered official proposals until a Codev topic is created and someone is committed to implement the proposal and they are moved up to the "Proposals with their own supporting topic".

• Accepted
• Parked. Deferred to later release, or pending owner. But will most likely be accepted when driven by owner.
• Not accepted.
• Discussion still ongoing on proposal topic. Not ready for release meeting decision.
• Ready for decision at next release meeting.
• - feature is accepted and done.

Current Proposals With Their Own Supporting Topic

1. DakarPerformanceIssues - KennethLavrsen
   We need steps to bring TWiki back towards at least Cairo performance.
   • The main contribution to address this in 4.1 is the profiling framework. See BenchmarkFramework
   • The framework has been added to 4.1. It will for sure be developed further but does not block a 4.1 release.

Parked and Not Accepted Proposals

1. (Parked) TWikiFns (previously called TWikiTags) - ML
   • Accepted but owner is for the moment not working on it. So it seems this is de-facto deferred to 4.2 or later but not rejected.
2. IncludeShouldIncludeSettings - ML
   • The initial answer is NO but we are willing to bring it up again if new arguments pro are tables on IncludeShouldIncludeSettings
3. (parked) PreInstallSmartEditAddOn - PTh
   • Current status is that the Addon has a performance issue and will not be added as is.
4. EditTablerowPluginAsDefaultPlugin - TW - Need discussion at release meeting.
   • Request withdrawn by ThomasWeigert.
5. FindElsewherePluginAsDefaultPlugin - Start shipping FindElsewherePlugin -- WillNorris
6. (parked) TopicDisplayName - needs a champion
   • I do not see any progress on the discussion topic. The spec is defined but technical solution that will work is missing. A topic needs a driver who is committed to implement it. 4.1 is getting close and this feature requires a lot of time. I am forced to put it on park until we start on 4.2 for now KJL
7. GracefulFallbackWithPatternAndTwisty -- TW
   • Verified that Twisty is well behaved when JS is disabled. Proposal to not ship TwistyPlugin withdrawn -- TW
8. Discuss overlap between the newly proposed section parameters and the sections supported by MultiEditPlugin and SectionalEditPlugin. These should be harmonized (1+1=3). HarmonizeSectionParametersWithExistingPlugins -- TW
   • I have chosen to close this as rejected as the original topic had no proposal to vote for and the topic has drifted away. At the end there is another proposal which will need its own discussion topic if wanted persued. KJL
9. Documented Default Parameter Values For Include -- NielsKoldso
   • Last entry accepted on this topic before release of 4.1. Discussion already started. Concern raised. KJL
   • DocumentedDefaultParameterValuesForInclude - is rejected at EdinburghReleaseMeeting2006x11x13. Does not belong in core as proposed. And new proposal is for 4.2 in this case because of lack of time before 4.1 release. KJL
10. Extend TitleTag to support TopicDisplayName. Page title can be set, but needs a shortcut notation like ^SomeTopic and a search parameter to use the page title in search results. ML See below.
    • TitleTag which does not even exist on Plugins web is naturally Not 4.1 relevant. KJL

Completed Proposals

• ExtensionInstaller in configure - CC
  • Accepted and merged into TWiki4 branch.
• AutoIncTopicNameOnSave - PTh
  • Accepted and merged into TWiki4 branch.
• MainTWikiPreferencesOverridePluginSettings - PTh, TW
  • Consensus is that this is accepted with additional actions.
• PatternSkin update that uses TwistyPlugin instead of Contrib - improved speed, better prepared for plugin/contrib updates: Bugs:Item1704 -- ArthurClemens - 28 Jun 2006.
  • This has been visible on Bugs (very visibel so noone can have missed it because of errors that are now fixed) and noone has protested against this so it is assumed accepted that 4.1 also needs TWistyPlugin installed and activated. KJL
• Template rendering with parsing of newlines - better predictability. The template code currently strips newlines from the start and end of template definitions, making it a lottery what you get. This change removes that newline stripping, making writing templates much easier. Bugs:Item1640 -- ArthurClemens - 28 Jun 2006
  • With the release of 4.1 this will break all other skins than Pattern, Classic and Nat. Do we have the docs ready to help skin authors do the updates needed which we can link to from release note?
  • We need to make sure that TwistyPlugin is enabled when PatternSkin is default. Otherwise the skin breaks and users won't have any idea what hit them. I guess that means having this plugin always enabled when shipping?
• ProposedChangeToWikiWordSpec - ML
  • Accepted on the condition that unit test cases and docs are updated and pass (ask for help if needed)
  • KennethLavrsen has taken ownership of this. Feature is implented in code, unit tests are added, docs are updated and Javascript is updated as well. Complete.
• Support in configure for separating webs. Specifically, USERSWEB and MAINWEB, TWIKIWEB and DOCWEB. This is currently implemented in develop and being used successfully. ML
  • The 4 variables are now defined in TWikiPreferences in TWiki4 branch. But no additional support in configure. And probably will not be within scope of 4.1. There will probably be needed a large discussion before anyone attempts to make such a split. And the current development of having plugin settings in configure may make the need to split TWiki web into a DOC and TWiki (settings) will seem much less relevant.
• Bugs:Item2900 Refactored TWiki::UI::Edit::edit: Allows reuse of code. -- ThomasWeigert
  • A code refactor was done but no API change is asked for. The code itself was discussed in the bugs item before checking it in. No objections to the checked on the twiki-dev mailing list. I see no need to discuss at release meeting. API change if desired requires formal Codev discussion. KJL
• Bugs:Item2575 Need the ability to protect formfields from being altered during rendering: When using custom templates, sometimes one does not want vertical bars or newlines to be rewritten. Added flag consistent with %SEARCH%. -- ThomasWeigert.
  • This simple enhancement was simple, compatible, discussed with Steffen and no objections on twiki-dev. No need to discuss at meeting. I have simple marked it done. KJL
• Bugs:Item2896: To allow, e.g., EditTablerowPlugin to take form definitions from variable yet reusing TWiki::Form::new, refactored that routine. -- ThomasWeigert
  • No need to discuss. Marked as Done KJL
• PalettablePatternSkin - Main.MartinCleaver
  • There was agreement on the topic. We has the resolution clarified. Noone objected to the work already implemented. Done. KJL
• MergeExtendedSelectPluginToCore - Start shipping ExtendedSelectPlugin -- ThomasWeigert
  • This was raised as a bug report. And the solution was to merge the ExtendedSelectPlugin into the core. There has been voiced a wish for this to follow the release process so a topic is available for discussion.
  • This was automatically accepted the 14 Oct 2006. [[KJL]
• OrganizeTWikiVariables - haj
  • Decision made at EdinburghReleaseMeeting2006x10x02. PeterThoeny has removed the VarXXXX topics that are admin types as the action for release 4.1. Done.
• CustomizableNewWikiWordLink - nice enhancement, no brainer -- MD
  • Accepted at EdinburghReleaseMeeting2006x10x16 with current layout as default.
• DateFieldPluginAsDefaultPlugin - Start shipping DateFieldPlugin -- WillNorris
  • - The original proposal rejected at EdinburghReleaseMeeting2006x10x16
  • Consensus reached that it is OK to include function in core. Discussion on DateFieldPluginAsDefaultPlugin should define how to include function in core. ThomasWeigert has committed to implement this.
• - PreventLinkToOneself, using 2 new CSS classes -- SvenDowideit
  • Discussed at EdinburghReleaseMeeting2006x10x16. Answers given and code being checked in with no CSS and doc update only.
• NeedSpecForFormValueInitialization - Need to clarify the spec -- ThomasWeigert
  • Implemented per EdinburghReleaseMeeting2006x10x30. TW
• Execute on earlier decision to retire SupportFormsForSettingPreferences (see the discussion in UsingFormsForSettings). See Bugs:Item2302 - first step is to announce the deprecation when releasing 4.1.
• AddSectionParam -- AC. Accepted at EdinburghReleaseMeeting2006x10x30. HaraldJoerg implements together with ArthurClemens KJL
• - FixCheckTopicEditLock - ThomasWeigert Oops dialogs on lease conflict now working for both the standard Edit screen as well as when this happens to plugins. -- TW
• Sub-item: JumpBoxSlowInLargeWebs -- PTh - 18 Oct 2006
  • This one falls under the section "Feature tracking of minor enhancements and bug fixes" in TWikiRelease04x01Process and can be implemented right away -- KJL
• FlexibleReturnFromEdit -- TW per "Feature tracking of minor enhancements and bug fixes"
• PluginHandlerForContentMove - PTh
  • Proposal voted with 5 votes for and 0 against at EdinburghReleaseMeeting2006x11x13. Peter Thoeny is driver. KJL
• TemplatePathIsCounterintuitive - Main.MartinCleaver
  • TW added this as a configure option
• TWikiJavaScriptRefactoring -- AC
  • I consider this complete in the context of 4.1 KJL

1. TemplateAffectsTextarea -- TW
   • Accepted as hidden feature
   • To may best knowledge completed as hidden feature as agreed. KJL

Ideas

None of the ideas below are considered agreed or disagreed. They are just ideas to be picked up KJL

The following have been proposed but have no champion, so won;t be discussed further until someone gives them some TLC.

1. PluginTranslations - bring translations to plugins in a way that does not eat too much performance. No code or spec yet.
2. Make attachments accessible through viewfile, with a UI that allows a trusted user group to export certain attachments to be directly accessible via apache
   • general cleanup of the attachment code to make the rendering and usage more generic, allowing over-rides in UI, store mechanism and access semantics
3. some design and consideration to the upgrade code
4. enumerate priorities for the build system - not only is the official release build progress unfinished, but we need to find out what we can do for non-official releaser too (like Anton!)
5. Fixing as many of the "Normal" bugs as possible. The focus for the patch releases are the release blockers, and normal and low bugs tend to fall by the wayside.
6. I'd like to see TWikiShell as part of the build, and that it would probably require some participation from me to make this happen. -- MartinCleaver
7. Not strictly a feature, but we need to implement what we decided in SingleBranchPluginDevelopment -- PeterThoeny
   • This may need some rethought, as DEVELOP hasn't worked exactly as was hoped for. Hopefully nothing major will have to change, but short-term and long-term release code are commingled in DEVELOP, which makes it hard to sort out what is what.
8. Merge some of MoreFuncContrib into TWiki::Func.
9. Bugs:Item2400 (Add param section) so AJAX applications can retrieve sections of topics
10. Write doco that encourages Plugin writers to transition to the new 3 tiered level of settings. In particular, encourage them to leverage the ability to create cfg files to configure settings for plugins. -- ThomasWeigert
    • Moved this to from DEVELOP merge one liners to ideas since there is no discussion topic. KJL

Fns And Macros Discussion moved into a separate topic to allow a focussed discussion there and and more general one here.

Discussion

For information - I will be opening up discussions and try to make people agree or disagree with the topics in WhatIsIn04x01 as described in TWikiRelease04x01Process. Not because I am a passionate debater or have strong oppinions on all of them. I am not filling the role "customer advocate" together with Steffen. The goal is to get as much as possible discussed here on Codev so we can go straight to voting at release meetings. Otherwise the meetings will last forever.

-- KennethLavrsen - 26 Sep 2006

Hm, I'm curios: Has a release date for 4.1 been discussed yet?

• No update on release date since July. But I am trying to gather the bits and pieces now to see what is in and what is not. We are getting close enough that we need a release manager to step forward. -- KennethLavrsen - 27 Sep 2006

-- FranzJosefSilli - 26 Sep 2006

What about all the other improvements that have been made on the TWikiRelease04x00 branch? Do we need to bring each one up separately here?

-- ThomasWeigert - 26 Sep 2006

What the TWikiRelease04x01Process addresses are the major things like new features or changes to the spec or changes to plugin API. All the small incremental things are still just tracked as Bug Items and if people disagree because of a code detail they will know how to speak up. The new process is meant to be faster and simpler than before.

-- KennethLavrsen - 26 Sep 2006

Great. Just wanted to make sure these are not lost...

-- ThomasWeigert - 26 Sep 2006

I have tried to add some icons and updated status so we know what needs to be done for each topic and so that only topics ready for decision are being brought up at next release meeting. Hope it will work out.

-- KennethLavrsen - 27 Sep 2006

What are the actions still needed for MainTWikiPreferencesOverridePluginSettings ? I believe this is all done.

-- ThomasWeigert - 01 Oct 2006

Added a icon to the list above so we can see when a task is complete.

-- KennethLavrsen - 01 Oct 2006

The proposals on this topic is growing faster now than getting done.

We need to consider a feature freeze very soon and defer more large proposals to 4.2. Otherwise we will not release a 4.1 any time soon.

-- KennethLavrsen - 05 Oct 2006

I removed these 4. They are not features that needs decision at release meetings. They are bugs reports that the reporter want help or attention to. It is a little too much work for me if I also have to start pushing those via this topic. But by all means - add them to the agenda for next meeting if you want them discussed. As we approach release we will be discussing all open urgent and requirement bugs that block a release anyway. Meeting invitations are sent out on twiki-dev mailing list. All are welcome at the meetings and can vote.

1. Bugs:Item2453 TOC does not work correctly when page is generated using URL parameters (requirement) -- ThomasWeigert
2. Bugs:Item2788 Pattern Skin lost the generic oops template. Reuse opportunity.
3. Bugs:Item2572 Printable looses URL parameters (requirement) -- ThomasWeigert
4. Bugs:Item2771 Print view changed in backwards incompatible way (requirement) -- ThomasWeigert

On 2788 it seems the initiative is yours Thomas. Crawford proposes that you implement what you suggest.

-- KennethLavrsen - 05 Oct 2006

OK. I just want to make sure that the Bug fixes are merged into the release when done...

-- ThomasWeigert - 06 Oct 2006

Don't worry. Anything checked into the MAIN SVN branch is automatically in 4.1 unless someone reverts the change. The one-liner list above addressed the enhancements that had been checked into DEVELOP branch and not yet merged to MAIN (or TWikiRelease04x00 before we moved to MAIN). And all those have been addressed now which is good. You do not have to list the small Bugs driven changes on this topic. But anyone that feels a bugs items needs a Codev topic discussion can take that initiative. But the whole point of TWikiRelease04x01Process is to make it minimal and efficient and only take the important decisions to release meetings and only if we disagree.

-- KennethLavrsen - 06 Oct 2006 (updated 11 Oct 2006 - we use MAIN now)

I have had to be a little more sharp in my role as customers advocate. I spend too much time just creating topics for others and moving discussion entries that belongs to the proposal topics.

I am beginning to delete the one liners without discussion topic that are added here. Please add a proper Codev topic and please discuss on the discussion topics and not here. We will loose the overview on this topic if all proposals are also discussed here.

The status messages below each proposal bullet are being heavily refactored. They were meant to be a short status and not discussion threads.

-- KennethLavrsen - 15 Oct 2006

I added this item as I noticed that there is more and more javascript sprinkled throughout the generated topics. I somehow recall that our goal was not to rely on javascript unless absolutely necessary. Clearly we have drifted away from that goal. I would like this reviewed for the 4.1 release, so we don't get stuck with code that we don't really wanted. See also Bugs:Item3100.

This is not a feature request, but a request for analysis of features that have been added before they are released.

-- ThomasWeigert - 06 Nov 2006

Removed. There was no discussion topic and I cannot see how we can vote yes or no to a blury discussion. These things are discussed in normal Codev topics. Otherwise it all becomes very confusing here.

-- KennethLavrsen - 06 Nov 2006

Thomas, please create a discussion topic and provide us examples of your concerns.

-- ArthurClemens - 06 Nov 2006