Cairo Release
Released as TWikiRelease04Sep2004 (previously TWikiRelease01Sep2004, TWikiRelease02Sep2004 and TWikiRelease03Sep2004)
Next Release codenamed DakarRelease
This topic contains pushed-back
To-Do items and several
Nice To Have items from
BeijingRelease.
TWikiContributors - please add to and/or comment, but please keep in mind the
TWikiMission.
Introduction
The upcoming production
TWikiRelease is code named Cairo and is due to arrive in Q3 2004. The Cairo release sits between
BeijingRelease and
DakarRelease.
Lesser wanted features (i.e. feature requests where code changes are difficult and the requester has not contributed code) are less likely to be implemented in the near future. Moral: get someone to code your change and make it available in a way that is easily incorporated by the
CoreTeam.
Dev Flow Restructuring
Before the
CoreTeam dives into spec and coding work we should review and
RestructureCodevWorkFlow.
Overall goals
TWikiMission specifies the overall purpose of the project.
Cairo Release focus:
(Please add feedback at the end of the topic)
Search for non-bug topics marked as Scheduled for CairoRelease:
Search for
Bug topics marked as Scheduled for CairoRelease:
See also
CairoReleaseSummary and
CairoReleaseUpgradeGuide
"Nice to Have" List
Search for unsponsored (
AssignedToCore not set) features marked as Scheduled for CairoRelease:
moved to
DakarRelease
Change Proposals for CairoRelease still being worked on
Search for topics that still need work:
Change Proposals for CairoRelease Awaiting Merge
Search for topics Proposed for CairoRelease that are
waiting for merge to the MAIN branch:
Change Proposals for CairoRelease Merged to Main SVN Branch
Search for topics Proposed for CairoRelease that have been
MergedToCore or
ImplementedAsExtension:
Release State Summary
See also
CairoReleaseSummary and
CairoReleaseUpgradeGuide
Known issues
See
KnownIssuesOfTWiki01Sep2004 and
KnownBugsOfTWiki01Sep2004
Feedback and requests
There's an interesting article over at Mozilla.org that is quite relevant (to a removed discussion about release timing - sd), about
bug-reporting etiquette - discussed on
this Slashdot thread.
--
RichardDonkin - 20 Mar 2003
The delay is attributed to busy core team members and, frankly speaking, also to the countless hours I spent in bringing the community back together after the many vocal "suggestions" we had, driven mainly by people with interests not matching the
TWikiMission. (Not to say that suggestions are not welcome; to the contrary, improvements are driven by constructive suggestions). Moral of the story: We will get faster releases if we concentrate on features and process improvements, e.g. the fun of open source programming
--
PeterThoeny - 01 Dec 2003
Release schedule
As there is still no releasedate in sight some consequences should be drawn in the next time. Regular releases are important to held up the community. As for myself, I´m not willing to update to some beta release and in result of this I continously loosing contact to the ongoing development. I think I´m not the only one who is in this situation and it has to be changed!
Sven already said that features should be re-assigned to
DakarRelease. A good start would be to set finally some dates for release milestones, otherwise it would be a neverending story. My Proposal would be:
- feature-freeze: re-assessing all features with less than 100% spec
- implementation-freeze: re-assessing all features with less than 100% impl
- documentation-freeze: re-assessing all features with less than 100% doc
Two weeks for every milestone should be enough, and within 1 1/2 month a release will finally come up of the dark on TWiki.org.
--
AndreUlrich - 19 Apr 2004
I think two weeks might be a bit too tight, but I like the idea of a progressive freezing process.
Perhaps
DakarRelease should concentrate on features relating to installation and that help the release workflow on TWiki.org so that these frequent releases (and Beta's) can be more easily managed/tested/applied. (Do the thing first that makes everything after it easier)
--
SamHasler - 19 Apr 2004
I updated the
TWikiContributor with the list of
CairoRelease code contributors. This is based on persons listed in the
AssignedTo field of topics marked as
CairoRelease. Please help check that no code contributor is missing in the
AssignedTo fields.
--
PeterThoeny - 09 May 2004
Peter, could you please indicate whether this beta release is suitably stable so that it begins to make sense to port a large deployment with many customizations to this release? I understand that there are significant changes from Beijing. What I want to avoid is to port my installation, only to find that another large port is required in the near future to further significant changes.
--
ThomasWeigert - 09 May 2004
Thomas has a good point - is the core team finished with major refactorings that will go into
CairoRelease? or is there work still inprogress? If we decide that we should be done - so that we concentrate on polishing and docco, then people like Thomas can start their early integration work - which will help with the testing and thus improve our bug fixing phase....
(Thomas - once you have seen this - I'd like to move this discussion to
CairoRelease)
--
SvenDowideit - 09 May 2004
It would be great to have an answer. Yes or no, either way is fine. I am not trying to be pushy, just trying to understand where we are at, in order to schedule our deployment.
--
ThomasWeigert - 14 May 2004
I do not expect big changes, you can start migration work. See my notes of 20 Apr 2004 on pending stuff.
--
PeterThoeny - 20 May 2004
Lets target the 01 Aug 2004 release date for Cairo. Help in pending documentation, bug fixes and feature implementation is greatly appreciated.
I will be travelling in Japan and Hong Kong for the next 4 weeks and cannot be that active during that time. I will follow-up more in July.
--
PeterThoeny - 05 Jun 2004
The current
TWikiBetaRelease includes also the
EditTablePlugin. That plugin has bundled the
Mishoo DHTML calendar. However, this seems to be the wrong place for the jscalendar: Any form could use this calendar and it also might make sense to include a flattened calendar in a topic view. Also, the calendar included with
EditTablePlugin is already outdated; there is already a newer version on
sourceforge.
I would recommend to
- Unbundle the jscalendar from EditTablePlugin, and
- Include the jscalendar either into core or as a generic plugin that applies to any form field.
There is much discussion on this topic in
JavaScriptDatePickerForForm. I have attached an updated patch (to
TWikiBetaRelease2004x05x07) that includes jscalendar in core and unbundels
EditTablePlugin. An alternative might be to include the jscalendar along the lines of
FormFieldsPlugin.
CrawfordCurrie has kicked off a discussion of this issue in
AddJSCalendarToCore.
--
ThomasWeigert - 06 Jun 2004
Peter being on holiday has thrown the Cairo status into sharp relief. Basically, it's stalled. A large number of jobs have been left unfinished. Without Peter here Sven is the
only core team member actively working towards getting this release out of the door, and he is totally overloaded. To try and redress this I've been helping him establish what the current status of this release is, and trying to help clear some of the blackages to us getting a release out of the door. I now believe that the status shown here
is as accurate as it can be.
Everyone, anyone who is assigned to a piece of work, either as developer or core team sponsor, please, please please do whatever you can to close off on these pieces of work - even if that means finding someone else to do the work for you.
Everyone, anyone who is
not assigned to a piece of work, consider what you can do to help get this long, long awaited release out of the door.
--
CrawfordCurrie - 02 Jul 2004
I'd like to suggest that we go into
FeatureFreezeMode at the end of friday 23/Jul/2004 (which would mean all work not at 100% Spec & 100% Impl would be pushed to
DakarRelease). Then we can try to get a
ReleaseCandidate out on the weekend, and have a week(ish) to finalise any missing docco and fix any bugs that get found.
Peter, is this possible for you?
--
SvenDowideit - 21 Jul 2004
I could not progress as fast as I wished because of bug fixing. I still need at least the weekend to finish some feature enhancements. Lets shoot for Monday, 26 Jul.
--
PeterThoeny - 21 Jul 2004
I will need until Wed 28 end of day to go through all templates and create something shippable. If we maintain 26 Jul, we better postpone pattern skin to Dakar.
--
ArthurClemens - 25 Jul 2004
Moved
KennethLavrsen's report to
CairoPerformanceIssues. We need to look at the performance, his numbers are alarming. Who has time to investigate the bottlenecks?
For this, Arthur's changes and my pending changes we should shift the code freeze to Wed 28.
--
PeterThoeny - 26 Jul 2004
I would like to ask that instead of just pushing out the release, could you please build a beta first, so that people can test what there is featurewise in
CairoRelease?
I doubt I have time, and I expect that any real advancments in performance are going to be risky, which is why i pushed this as the raison d'être for
DakarRelease.
--
SvenDowideit - 26 Jul 2004
See also
CairoPerformanceExperiments for data on performance. Hopefully this may help provide some focii. Personally I think that to hit performance effectively requires some major code refactoring, and is high risk, but if you think it can be done meaningfully for Cairo.....
--
CrawfordCurrie - 26 Jul 2004
OK, I will build a Beta tomorrow.
As for performance improvements, probably better to tackle only the low hanging fruit and avoid large code refactor. Possibly comment out out a recent feature in case it is a performance hog. Please follo-up with performance discussions in
CairoPerformanceIssues.
--
PeterThoeny - 27 Jul 2004
Any chance of a drop-dead date for a release?
It would be nice to be able to time "getting all the little things done" appropriately.
Instead of/as well as a drop-dead data, a "notice period" would be very good to know
about. Knowing that there will be 48 hours to go will help ... it would be sad to be
working on something and suddenly find the release went out unexpectedly.
(eg -
UpgradeTWiki script and more importantly it's documentation in
CairoUpgradeGuide, which
is yet to be done).
--
MartinGregory - 30 Jul 2004
I have temporarily changed the twiki logo in
WebTopBar. This is a public reminder to eiter change the image url back to %TWIKILOGOURL% for the final release.
--
ArthurClemens - 01 Aug 2004
We are getting really close for
TWikiRelease01Aug2004 Pending steps before the release:
Can we shoot for a code freeze this Friday? And release on Sunday? Or, how much time is needed to finish
PatternSkin and
UpgradeTWiki Script? Possibly release the TWikiUpgradeScript as Alpha, as we did with
RcsLite for
TWikiRelease01Feb2003?
--
PeterThoeny - 03 Aug 2004
I think there will be something that is more help than nothing with the upgrade script by the end
of the week, and the documentation doesn't seem overly onerous.
The upgrade script certainly needs some sort of caveat (alpha, beta, caveat emptor, whatever),
especially since not only is it lightly tested but it doesn't actually do everything we would like it to.
--
MartinGregory - 03 Aug 2004
PatternSkin to do list:
|
Add Go box |
|
Better top bar, possibly with Go box |
|
Web-configurable WebLeftBar |
|
Documentation of css styles |
|
Final browser tests |
Dakar |
Fix bug with USERLAYOUTTOPIC and USERSTYLETOPIC (RelativeTopicPathAlwaysAddsWeb) |
|
"How to" documentation - will be elaborated later |
|
Create plugin package |
--
ArthurClemens - 06,08 Aug 2004
It appears that substantial work remains to be done on
PatternSkin. In particular, the documentation is usually a big effort. I suggest we drop packaging this skin with the Cairo release, as there is no harm done having it as a download, as all the other skins. It is better to get Cairo out as soon as possible and get the most critical performance issues addressed.
--
ThomasWeigert - 07 Aug 2004
I said:
setlib.cfg appears to be shipped like this:
# ATTENTION: Set to absolute file path:
$twikiLibPath = '../lib';
It strikes me as strange to have instructions saying "absolute file path", and
ship with a relative file path.
Of course, this relative path is the one chance the user has of
the thing working unmodified, so the relative path makes sense in that
case. So why the instructions for "absolute path"?
(this probably belongs somewhere else, but where?)
- Needs to be absolute because if TWiki changes the current dir (e.g. after a SEARCH), additional Plugin modules that load late fail to load. -- PTh
--
MartinGregory - 08 Aug 2004
Two items remain before
UpgradeTWiki is really ready:
- Someone to review the default TWiki.cfg contents
- Me to check its results using TWikiReleaseTrackerPlugin
MartinCleaver has given me new instructions about how to do the latter - I should get to it within 12 hours.
--
MartinGregory - 10 Aug 2004
We can release in a few days, pending mainly doc work.
As for the release "number" on the first of the month, we were targeting 01 Aug 2004. I think it is better to call the release 01 Sep 2004, also if we release in the next few days. For the press release it sounds better to announce a release date in the future then in the past. Any objections?
- Motion seconded! Release dates which predate the actual release cause nothing but trouble and confusion. -- MattWilkie - 10 Aug 2004
- Motion thirded, with knobs on. A wise decision if ever there was one. -- MartinGregory - 10 Aug 2004
--
PeterThoeny - 10 Aug 2004
We need to decide if to enable the
PatternSkin by default in the distro. We should because it makes a professional first impression.
The question to solve is if the new skin performs well with the many includes on css files and page elements. If there is a noticable performance drop compared to the classic skin we should ship TWiki with the classic skin enabled, and address the performance after release.
Anyone can help in benchmarking? Best to use the
ab
utility.
--
PeterThoeny - 17 Aug 2004
See
CairoPerformanceExperiments.
(if anyone else wants to run benchmarks I'd me delighted to share my scripts).
--
CrawfordCurrie - 18 Aug 2004
Of course I am interested. For me much is at stake, I wouldn't like to see people not using PatternSkin because it is too slow. Perhaps I can make a few performance improvements now. See
CairoPerformanceExperiments for futher comments.
--
ArthurClemens - 18 Aug 2004
Shh, secret: The
TWikiRelease01Sep2004 (
CairoRelease) package is now available:
TWiki20040901.zip,
TWiki20040901.tar.gz. Please give it a try before I announce it widely in a few days, we can update some docs if needed.
--
PeterThoeny - 30 Aug 2004
Should all the topics listed above be changed to have 100% and be
FeatureDone to keep them off topics like
FeatureUnderConstruction and
DocsToDo? What about those classified as
PatchAccepted and
FeatureDocumented, should they also be changed to
FeatureDone?
- This is followup work. Set doc only to 100% if done. -- PTh
Aside: changed the classification of this topic to
FeatureDone to match
AthensRelease, although I note that
BeijingRelease is classified as
DefineTerm.
--
SamHasler - 11 Sep 2004
MattWilkie noted on
TWikiIRC that TWiki20040901 is not listed on
http://twiki.org/release/ - is this deliberate?
--
MartinCleaver - 02 Oct 2004
Oops, that's an ommission. Is fixed now.
--
PeterThoeny - 03 Oct 2004