Item1175: Upgrade foswiki.org to 1.0.7

As the documentation (including InstallationGuide, UpgradeGuide, and their HTML-equivalents contained in the root of the Foswiki distribution) refers to the foswiki.org web site, can the foswiki.org web site be upgraded to 1.0.3 so the links will point to the current versions of the document?

Going forward, can a work item be placed on a production release checklist to upgrade the foswiki.org site to the newest release (or at least upgrade the documentation in the System web)?

---

Kenneth, I am putting you in the WaitingFor field so hopefully you will see it before releasing 1.0.3 (and you can judge if this item should be done before the release of 1.0.3). Also putting Rafael in the field, as I think nominally the WebsiteFacilitatorTaskTeam is responsible for the web site? -- IsaacLin - 01 Mar 2009

---

There is no way I can commit to also update the web site when I build a release.

It already takes me two full working days to prepare a release.

I cannot take on more work in that process.

-- KennethLavrsen - 02 Mar 2009

Absolutely not expecting you to do this work, Kenneth -- but I believe a new release needs to be co-ordinated with whomever is responsible for keeping the web site up to date. It is important to have the latest documentation available on the web site when a new distribution is released. Otherwise users will be confused when selecting links that go to foswiki.org and see different content, or even encounter broken links. -- IsaacLin - 02 Mar 2009

I communicate my release plans all the time. I am sure all in the InfrastructureTaskTeamGroup are aware of my plans.

Problem is that this site is not a stock out of the box Foswiki. It has special settings and a special skin. Doing an SVN update could leave the site in ruins.

So there is easily a 1-2 day effort to test things carefully before upgrading. Now who has that kind of time while still doing your normal day job?

The most important documents to update are release notes and installation guide. I normally manually update those here when I publish a release. That is 2 or 3 topic updates.

-- KennethLavrsen - 03 Mar 2009

root@foswiki /home/foswiki.org/trunk/core # svn info
Path: .
URL: http://svn.foswiki.org/trunk/core
Repository Root: http://svn.foswiki.org
Repository UUID: 0b4bb1d4-4e5a-0410-9cc4-b2b747904278
Revision: 1878
Node Kind: directory
Schedule: normal
Last Changed Author: KennethLavrsen
Last Changed Rev: 1878
Last Changed Date: 2009-01-08 12:20:47 +0000 (Thu, 08 Jan 2009)

need to create http://svn.foswiki.org/branches/foswiki.org from revision 1878 and then merge in http://svn.foswiki.org/tags/FoswikiRelease01x00x04/

-- WillNorris - 11 Apr 2009

I've been busy this week trying to merge over 2 things:

1. The changes we made locally, so they get into the foswiki.org branch
2. The changes between the foswiki.org branch and the Release01x00 one

The first ones have been my first bunch of commits, which Will reviewed and should have integrated directly into the FoswikiSiteSkin, the second ones have been much more problematic because we branched from trunk, where we have all extensions, and we merge to Release01x00, where we only have a few. Maybe with svk it would have been simpler, anyway, I think I've finally done it.

You're welcomed to try and test it on http://test.foswiki.org which I used once again to test our migration. This contains a copy of the current production website, so any modification to pages, new items, etc... WILL NOT BE REFLECTED on the production http://foswiki.org website. So knock yourselves out trying things, especially the GET XSS "bug".

-- OlivierRaginel - 29 Apr 2009

We also need to rename manually all the renaming that was done automatically by TCP

-- OlivierRaginel - 30 Apr 2009

What can be done, to get it moving faster? It seems as if there was no action since April on this issue.

-- MartinSeibert - 21 May 2009

PersonalInfoAddOn needs to be updated to work with 1.0.5; maybe other plugins installed at foswiki.org have GET issues with 1.0.5, dunno.

-- WillNorris - 21 May 2009

What is it that does not work with 1.0.5 in PersonalInfoAddOn? I see 3 places with a form and all 3 have method="post"

-- KennethLavrsen - 26 May 2009

details on Item1507

-- WillNorris - 26 May 2009

Bumping version number to 1.0.6 and merging things in Subversion.

-- OlivierRaginel - 29 Jun 2009

I have set up a stock 1.0.6 (from tarball) on http://six.foswiki.org/. I'm sure its not perfect, but unless there are no disastrous things happening (eg. support web breaks, task web is non-functional, ie essential functionality is lost) i plan to migrate this to the production environment tonight.

After this, keeping things up to date should be a relatively straightforward job. I will request a 'staging.foswiki.org' where i can do this for future releases so we can test a bit before going live with a new release.

-- KoenMartens - 15 Sep 2009

Had a play around and everything seems fine. In particular I checked the wiki apps (tasks, support, feature proposals) and they are working fine. Good work

Only thing I can see is that we have a "Jump" box in six, but not on live. Is this intentional? Personally I like the Jump box, but I guess there are good reasons not to have it.

Perhaps staging.foswiki.org could be an svn install from 01x00, so we would be able to test the upcoming release (such as 1.0.7) in the same way we can test trunk at the moment?

-- AndrewJones - 15 Sep 2009

I thought WillNorris was clear enough with his:

• details on Item1507 -- WillNorris - 26 May 2009

Either we decide the AttachContentPlugin, which is a dependency of PersonalInfoAddOn, is not important, and we either ditch it, or at least make it behave somehow, or we think it's an important part of our website, and we wait that this plugin is fixed before we upgrade.

I personally think we should wait, which is why http://test.foswiki.org, which is a 1.0.6 installation with all the required plugins, made from the foswiki.org branch, hasn't become the live site for some months.

If I may, I would strongly oppose a switch to six because it's been once again done manually. Sorry Koen that you've spent all this time doing this, testing the 1.0.6 release and fixing stuff, but I see no good reason to keep doing it manually.

The main point I see people giving for using the tarball is that we should eat our own dog food. And this, for me, is not using the tarball. What's the ratio of people using the installers (Debian, FreeBSD, Windows, OS-X, ...) compared to the ones downloading and using the tarball? Then, why don't we use the FreeBSD ports?

We (Will and I) have spent many hours doing the branch thing because it is easy to:

1. Keep track of configuration changes
2. Keep track of plugin installation
3. Upgrade -- Yes, merging to a branch, with a decent tool, is a matter of minutes. Then, svn update, et voila!

If we go the tarball way, we will have to:

1. Backup and document every configuration changes
2. Have some page showing which plugins are installed (and used, so InstalledPlugins might not be sufficient), maybe why too
3. Use the upgrade tarball and eat our own dog food

If we go the ports way, we will have to:

1. Backup and document every configuration changes
2. Install all plugins using the ports (I hope GregLarkin can cope with plugins too)
3. Use the ports to upgrade

For me, we need 2 decisions:

1. Decide what plugins are mandatory for our website, from a UI perspective, therefore this decision has to come from the UserExperienceTaskTeam and/or the WebsiteFacilitatorTaskTeam
2. Decide which way we want to go, and this has to come from the InfrastructureTaskTeamGroup

-- OlivierRaginel - 15 Sep 2009

First some technical info. AttachContentPlugin works fine. The problem is PersonalInfoAddOn which uses AttachContentPlugin in a way where it is called using a GET. And since 1.0.5 this has been banned.

We have fixed 200 bugs since 1.0.0. And among them are severe security holes that have been plugged. I cannot see why on earth you keep discussing a problem of minor little feature related to PersonalInfoAddOn which we can easily live without and at the same time not give a damm that our site has many severe bugs that nags us all every day and we have CSRF vulnerabilites that spammerns may already have used to plant spam on our site. Stop this nonsense discussion. It is a no-brainer that we need to get to 1.0.6 and in a week 1.0.7. And then we can fix the little issue with PersonalInfoAddOn.

Olivier nothing has happened for almost 9 months. And we are some that stop talking and start acting now. Either you help us. Or you stay away. But we cannot let ourselves be blocked by more talking. You say "I personally think we should wait". We know that. And we have had enough of waiting. We are acting now.

We are going the tarball way now. And this means that we can keep the site up to date.

You talk about task teams

• UserExperienceTaskTeam
• WebsiteFacilitatorTaskTeam
• InfrastructureTaskTeamGroup

The UserExperienceTaskTeam mandate was to work on improving the usability. Not for foswiki.org but for Foswiki. And until now they have produced discussions and nothing. Do not mix them up with getting the site to 1.0.6. If they want features they have to make them work on 1.0.6 and 1.0.7.

The WebsiteFacilitatorTaskTeam has also only produced discussions. We are still on 1.0.0

And then there is the infrastructure team which I am also part of. And we are acting now. The site gets updated to 1.0.6 and soon to 1.0.7.

There are plenty of good proposals on how to improve the home page. And they are all better than what we have. But nothing has happened because each time one comes with a great proposal another comes with a counter proposal which is also good but different. Result is that nothing happens.

The problem with all this is

• The task teams overlap in responsibility
• The task teams have no leadership. Noone takes the leadership role. Noone dares making decisions.

The release management team works because everyone knows I am the leader, and I dare making decisions. I always ask the community for opinions and often arrange a vote. I do not always decide. But I arrange a decision is made. And if the situation is a no-brainer I take the decisions right away. That is why we have released 6 times in 2009 and upgrade the site 0 times in 2009.

You may remember that I asked in a mailing list posting something like "Who is taking the responsibility... " asking for the server to be upgraded. I got a couple of nasty replies. But noone tool the leadership. Noone took the responsibility.

Koen took an initiative. Great Koen. You deserve nothing but credit. Both for getting the new server. And now for upgrading it. That is what we need. Leadership and initiative.

I am trying to take some leadership on getting the site updated with Koen now. And I am not going to wait any longer. It is a no-brainer that it is unacceptable to expose our project website to the CSRF vulnerability. It is nobrainer that we want the annoying bugs fixed that nags us daily.

Olivier. Instead of talking I suggest you fix the PersonalInfoAddOn. The problem is well described in the bug item and it is for sure within your skill set to fix it. If you start now you have it solved in a few hours. Meanwhile let Koen upgrade the site using the tarballs which means that any of us can maintain the site. And I feel more confortable that the web site runs the same way as with our customers. There are many things that are different in a pseudo-install. Especially if there are bugs in MANIFESTs. Plugin topics are also different after going through the build contrib. Let us keep it simple so all of us on the Infrastructure team can assist. As it is now only you and Will have the overview of the branch.

In a few days the 1.0.7 gets released and my goal is to have our site running 1.0.7 within 1-2 days after the release. From tarball.

-- KennethLavrsen - 15 Sep 2009

Ok, so from now on, you're also the InfrastructureTaskTeam dictator too.

I just wonder why you weren't so pleased and eager to help when I spent hours setting up test.foswiki.org which is very close to what six.foswiki.org is.

But now, you want to rush Koen's work because it is how you think it should be done. As for your arguments that only Will and I have the overview of the branch: http://trac.foswiki.org/browser/branches/foswiki.org should help. And I think Oliver or Sven, and maybe some others are well aware of it.

I'll stop this endless discussion because you will never listen to what I have to say. And I don't see why I should fix the PersonalInfoAddOn whereas you'll be pretty happy to ditch it so you can rush your tarball deployment.

Again, test.foswiki.org is six.foswiki.org, only 3 months old roughly.

Koen, please fix the System web before switching.

-- OlivierRaginel - 15 Sep 2009

Infrastructure dictator? Yeah let us call it that. Koen and I are filling a void. If you had finished the work you started 3 months ago and put the branch solution in production noone would have questioned your approach. It is not a role I want at all. And if someone steps forward and say "I will lead the infra team" then I will have disappeared before he has finished that sentence. I take this role for a few days only to get the server updated. I have more than enough work to do as release manager.

-- KennethLavrsen - 15 Sep 2009

Please, can everyone try to assume good faith? I'm pretty sure everyone wants the same goal; it's just the path to be taken that is an issue. I hope we can also agree that, as a general principle, sometimes a less optimal path that can be completed sooner is a better practical tradeoff, which does not preclude better paths being completed later. (The exact degree of compromise of course needs to be worked out.)

-- IsaacLin - 15 Sep 2009

Why can't we push Arthur to fix the bug in PersonalInfoAddOn? Or it's unimportant? I know it's open policy, but he's the author. I don't see anyone even attempt to fix a bug or inform Arthur to fix it, which is the core of this issue. Shouldn't most common extensions be conformed to all releases? Kenneth, you should be putting your effort to ensure that, not out of focus on other petty things like this.

Olivier and Will have spent good amount of time to ensure that a workable upgrade is doable within minutes without checking through any other configuration settings or whatever surprises you'll get from a non-standard installation. So I don't see why we should go ahead with the tarball solution. Not all setups are the same, so we can't always take Motorola as the standard.

And take leadership? Olivier has taken leadership on this just as Sven took leadership with SVN, and Koen with hardware, and Martin and I on the blog. Or do we have a policy that leadership is the whoever-can-do-it-now? That's not leadership, that's no different from any non-structured organisation. What difference is this to taking other's work, trash it, redo it and call it yours? That's disrespect, especially when there is already an organisational structure.

If we can't agree on how each of us do things, then I don't see how we are collaborating. Attaining goals shouldn't always be the priority, the processes matters too. And to me, that bug in PersonalInfoAddOn should be fixed - if not, it's a shame that our releases break due to common Extensions.

-- KwangErnLiew - 16 Sep 2009

I was hoping that for once a disagreement would de-escalate... As you may recall, I have been a strong proponent of having more process being followed. I believe the suggestion I made that task forces issue regular status reports would have been useful here, so the community would know the latest progress and how they could help. But note it has been over six months and four releases ago that I opened this item, and there is no forecast of how much longer this work item will take. Yes, I agree that task forces should be empowered to do their work and not feel like they can be overridden at any point; the flip side is that they need to take ownership of the problems in their way. Who is the "we" being asked to "push" for a solution to PersonalInfoAddOn? If this is a blocking issue, then the InfrastructureTaskTeam needs to figure out a way to move forward.

-- IsaacLin - 16 Sep 2009

Maybe Olivier and Will worked on something for months. But the result we never saw. The site stayed at 1.0.0. Olivier never said he has taken any leadership and we never saw any leadership activity.

Koen worked on the site upgrade for two days and now we are at 1.0.6.

I did not really take any leadership in this. It was Koen that did all the work. I just gave moral support. And by saying I had taken the leadership you would all shoot at me instead of Koen so he could get peace and quiet to finish the job. My days of server dictatorship are over. They lasted 48 hours. That was all it took. And I am so used to being shot at in this community that I did not mind taking another blast of verbal abuse.

The site is now running from a tarball. The tarballs is the result of the community work and what we offer to our "customers". And we can now keep it up to date using upgrade kits.

And if my upgrade kits are not good enough for foswiki.org then I will make them good enough because now I have an extra benchmark to go for.

If Olivier and Will wants to persue the SVN method nothing stops them. But please then document it before so the rest of us know how to do it as well because as it is now neither Koen nor I was able to figure out what had to be done.

With respect to PersonalInfoAddOn. That is one little bug for a minor feature. There are much more severe bugs that are now fixed.

• When you pressed edit and need to login and mistyped the password and tried again you landed on WebHome and had to navigate back to the page you really wanted to edit. Annoying like hell. Fixed now.
• People could plant an image tag completely hidden which - when viewed by an AdminGroup member - would save content to an admin only topic. Bug secutity risk that was plugged in 1.0.5
• People could send an email or create a topic that links to a 3rd party site which would lure a AdminGroup member to save content to an admin only topic without him knowing. A security hole that was plugged in 1.0.6.
• The many many bugs in 1.0.0 that was on full display on our site caused many bug reports of things people had seen only on our site. I have No Actioned many bugs that turned out to be fixed in the shipping version

And to round that off here is a table of more good reasons why upgrading to 1.0.6 was needed.

Item707	InstallationGuide has incorrect link to list of users
Item714	Add a Legacy engine, so Contribs that add scripts to bin dir can work
Item727	Comment plugin loses data
Item736	Comment plugin doesn't know about Compare Revisions
Item742	Wrong print in Foswiki::Engine::finalizeHeaders
Item744	Malformed HTTP-Expire-header => data loss after Back-Button in https preview page
Item745	Finalizing proof-reading of fr.po
Item750	INCLUDINGWEB and INCLUDINGTOPIC will cause confusion when used in an INCLUDE chain
Item751	Installed Plugins should be listed on the AdminTools topic explicitly
Item753	Foswiki::Time::parseTime has a major parsing bug for some date formats
Item754	found a pattern skin doc that uses T*
Item763	change /Foswiki to /System in foswiki_httpd_conf.txt
Item764	Additional extensions installed via configure "FindMoreExtensions" get not listed in the "Installed Version" column and are not "upgradeable"
Item767	AUTOINC in the title messes up merge and crashes
Item776	Installer truncates dependencies in plugins
Item781	Forms fields expand variables like $nop, $quote $percnt
Item791	Cannot set WEBHEADERART in pattern skin anymore
Item793	Print crops the page in PatternSkin and thus in Foswiki.org skin
Item818	Foswiki::Request::url doesn't honor $Foswiki::cfg{ScriptSuffix}
Item819	bad class selectors in template make it impossible to style certain elements
Item833	Missing SYSTEMWEB in foswiki_vars
Item835	Exchanged the current default skin by something which is not written in totaly broken html
Item836	view of raw information on a topic that doesn't exist causes BOOM
Item841	the warning parameter if ignored for Sectional INCLUDEs
Item846	Query search length operator not documented
Item855	Query syntax in IF statements does not work with underscore topic names
Item873	expired cgi session files not deleted
Item875	Small Docu update in func
Item885	bin/manage/Web goes BOOM
Item889	Documentation for protecting pub files with Apache incorrect
Item893	configure extension installer DOS's by doing a saveTopic and saveAttachment
Item904	Remove test strings
Item906	why are we using '.' to find setlib.cfg when FindBin is in Perl?
Item908	adding a script suffix seems to confuse the url parsing code
Item909	VIEW_TEMPLATE overrides preview template, leaving out all topic actions
Item913	JSCalendarContrib::addHEAD or Func::addToHEAD used in any xxxTagsHandler causes deep recursion
Item918	Small docu update for JSCalendarContrib
Item923	Adding two new fields to the default response header: Action and URI.

| Item926 | Foswiki.spec {AccessibleENV} must list FOSWIKI_ACTION instead of TWIKI_ACTION

Item928	Update documentation of Foswiki::Request
Item945	RcsLite corrupts file's history
Item952	email failure for password reset, pwd change and i think rego too oops output broken
Item962	Remove FOSWIKI_LAYOUT_URL, FOSWIKI_STYLE_URL, FOSWIKI_COLORS_URL from FINALPREFERENCES
Item965	{Register}{HidePassword} = $FALSE; not respected when the password is generated by Register.pm
Item972	Undefined subroutine &Foswiki::Form::Select::TAINT called
Item973	SEARCH adds extra separator for header
Item977	WebChanges eats first word of link text
Item980	Moving a topic doesn't update TOPICMOVED
Item990	Update graphics, html and css
Item995	When editing a form only, "Save and Continue" leads to the full edit screen
Item1002	InstallationGuide doesn't mention FoswikiStandAlone
Item1010	Configure opening and closing of panels is clunky
Item1011	Configure fails with cryptic error in Configure/Checker.pm line 315 when RCS is not available on the system
Item1014	Configure complains when extra spaces are added in data structure
Item1016	ISO time formats have no timezone designator
Item1017	EditTablePlugin again cannot save textareas with formatting because of wrong handling of new lines
Item1018	Protect verbatim class="xxx" when editing
Item1020	TemplateLogin corrupts origurl param
Item1022	?logout=1 ignores the requested topic and returns to original topic
Item1023	CommandAndCGIScripts is missing docco on ?logout=1 url param
Item1029	TemplateLogin provides status 200 if no username is give, changed to 400
Item1053	Fix broken HTML
Item1070	Line75 of Sandbox.pm has an excess $
Item1073	Configure should not load Plugins that are hidden - ie files starting with a dot
Item1074	Remove link from data form table in preview
Item1078	Remove unwanted spaces in default templates
Item1094	invalid expiry date for session cookies
Item1097	HIDECOMMENTS is broken
Item1121	Sync the default apache config with the ApacheConfigGenerator
Item5352	Improve Email address validator to be more correct.
Item5853	PurePerl taint error inspired fix.
Item5920	TWikiGroups shows all members twice
Item6128	Login names with dots not working properly
Item8051	Use of uninitialized value in list assignment
Item523	Small user interface improvements to configure
Item967	Publish the iterators
Item1015	Add "use factory settings" links to Configure
Item1049	Table improvements for configure's FindMoreExtensions
Item630	Fix the code in extender.pl to use UNIVERSAL::require instead of eval use
Item1119	Can crash foswiki by typing arbitrary meta into a topic
Item1123	Remove reference to Support.Foswiki01x00x00 in InstallationGuide
Item1124	EditTablePlugin cannot use Macros for the format string
Item1126	Change in 1.0.1 causes crash when you have standard installation and no LocalLib.cfg and we can no longer run unit tests on Windows
Item1132	Foswiki::Func::getPreferencesValue docco is a little weird
Item1134	Use of uninitialized value in string eq at .../lib/Foswiki/Meta.pm line 296.
Item1135	Missing API documentation
Item6018	GMTIME{}% does not return the right value for $week in ISO8601
Item1055	Find More Extensions should compare installed version with latest version
Item1172	Foswiki::Request::param fails if parameter name is 0 or ''
Item1173	Javascript error with find more extensions
Item1176	Search page jumps focus to bottom
Item1177	configure doesn't install dependencies
Item1184	CALC inside table is not working
Item1189	Typo PatternSkinCustomization
Item1197	configure extension installer fails with taint error
Item1198	configure extension installer reports all extension rev numbers wrong
Item993	Log is (too) inaccurate
Item1055	Find More Extensions should compare installed version with latest version
Item1172	Foswiki::Request::param fails if parameter name is 0 or ''
Item1173	Javascript error with find more extensions
Item1176	Search page jumps focus to bottom
Item1177	configure doesn't install dependencies
Item1184	CALC inside table is not working
Item1189	typo PatternSkinCustomization
Item1197	configure extension installer fails with taint error
Item1198	configure extension installer reports all extension rev numbers wrong
Item1212	save from preview does not work
Item1214	Add 'px' if no size unit is passed
Item1217	PatternSkinCssCookbookNoLeftBar advice could be a little more useful
Item1221	EditTablePlugin cannot read a TABLE tag with macros
Item1227	PermittedRedirectHostUrls don't show up in the configure web page
Item1236	foswiki has problems with "special" characters in usernames (e.g. +)
Item1242	EditTablePlugin cannot move rows correctly when we have footerrows
Item1267	statistics cronjob does not work
Item1268	EditTablePlugin javascript does not save the changes in the last row of a table
Item1274	admin tools topic should list WikiGroups topic.
Item1276	Setting new parent for a normal web seems to fail
Item1281	initial configure advice on creating admin user could be a little more direct
Item1292	EditTablePlugin puts line between EDITTABLE and TABLE with search results
Item1293	PurePerl SEARCH crashes on distributed topic
Item1299	Moving a web or single topic does not corrently update links in topics
Item1300	Foswiki::Store::createWeb uses hash values as keys when changing WebPreferences
Item1306	When your IP address changes after authentication you cannot reauthenticate and server may crash
Item1307	Moving a web does not correctly update links to the moved web
Item1308	EditTablePlugin has problems with included topics with included edittable definition
Item1316	Disable IP Matching by default to avoid problems for people moving between LAN and WLAN or using load share gateways
Item1332	querystrings with semicolon or & but no valid parameter assignment gives error log entries
Item8055	Adding TWiki::ListIterator and TWiki::LineIterator to TWikiCompatibilityPlugin
Item8072	Error in Bridge between TWiki::Time and Foswiki::Time
Item1604	Implement use of RELEASE tag for extensions in addition to VERSION
Item647	You cannot SEARCH for the Value of "0"
Item931	Correct and simplify the {AuthScripts} documentation in configure
Item978	rewriteshbang.pl does not work with files as extracted from tgz
Item1050	Explanation at {ExtensionsRepositories} is not clear
Item1214	In TablePlugin - Add 'px' if no size unit is passed
Item1343	TinyMCEQuickHelp has bad META format, missing line feed causes it to show in topic text.
Item1349	Sandbox executes "-" instead of requested program on Strawberry perl on Windows XP
Item1354	SEARCHDEFAULTTYPE causes confusing and the misspelling means that people think this is the problem
Item1358	EditTablePlugin deep recurses in many cases
Item1372	Plugin installation fails on Windows - extender.pl can't find Archive::Tar
Item1384	Creating webs with empty field values in the submit form fails
Item1388	View topic since and other settings are not connected
Item1403	Use of uninitialized value at lib/Foswiki.pm
Item1413	WebLeftBarSearch search field javascript not blanking box when focused
Item1416	TOC anchor links broken
Item1443	We still have 1.0 format in distributed topics
Item1451	Typos on TextFormattingRules
Item1453	Too hard to create new switchboard entries, doc is poor
Item1456	Access viewfile without web/file results in oops
Item1458	Don't allow saving data when http method is GET
Item1468	Topics with regex quantifier characters such as + in their names prevent other topics from being moved
Item1472	Remove bookview from WebSearchAdvanced. And update docu to warn about it
Item1485	_default web permissions are wrong
Item1493	More screen shows wrong link to parent if the topic is in a subweb.
Item1502	Raw Edit javascript for resize window and font does not work in IE
Item1505	Plugin installation fails on windows - read-only files cannot be replaced.
Item1524	Country list on registration form is not 100% alphabetical
Item5471	The character 0 cannot be replaced using the replace-funtion of the SpreadSheetPlugin
Item5791	Topics using parenthesis in name cause regex errors
Item8124	TCP TWiki web preferences too open
Item1374	Add New New $EMPTY(), $LEFTSTRING(), $RIGHTSTRING(), SUBSTRING(), $INSERTSTRING() functions to SpreadSheetPlugin
Item1381	Add depth parameter to META
Item1474	DocumentGraphics new images
Item4163	Bulgarian translation
Item1013	WysywigPlugin requires HTML::Parser but does not ship with it and does not give dependency in Configure
Item1341	TinyMCE converts TML lettered & roman numeral lists back to numbered lists.
Item1397	Typewriter-Formatting does not work in tables
Item1406	SpreadSheetPlugin and EditTablePlugin cannot coexist
Item1528	SpreadSheetPlugin's WORKINGDAYS calculates incorrectly
Item1535	"Typewriter" applied to bold text does not work
Item1538	Topics in Main web and new webs do not validate as clean xhtml
Item1544	EditTablePlugin no longer disables sort when editing
Item1553	PatternSkin top bar height documentation
Item1556	installer installing files twice
Item1567	configure links to non-existent anti-spam plugin
Item1588	Not clear that limit parameter in SEARCH works at topic level and cannot be used to limit multiple results
Item1593	Installing plugins from vanilla Foswiki 1.0.5 does not work
Item1605	Correct the code docco in Func.pm
Item1634	VarFAILEDPLUGINS links need fixing
Item1640	CommentPlugin writes "%" as html-code, which prevents the use of Macros
Item1644	RSS and ATOM will not display correct if cover is set globally
Item1668	The action template in CommentPlugin creates actions on one long line
Item1671	Pathnames of Attachments inappropriate in default Plugins
Item1673	Mising Content-Type in mailresetpassword.tmpl
Item1675	Add pptx, docx and xlsx to icon type list
Item1678	socket implementation of Net.pm is broken
Item1682	SEARCH does not work well with format being blank
Item1688	Left over enableTWikiMandatoryChecks in edit template causes warnings in JS debuggers
Item1689	JS error in preview
Item1690	Call to the resetpasswd script is not logged
Item1703	preview fails when an unknown view_template is used
Item1707	Deleting attachments in NAT and QUICKMENU do not work
Item1711	Some authentication services do not pass on parameters
Item1712	Warning in TopicUserMapping when Registration is disabled
Item1713	WebSearch does not pass excludetopic parameter
Item1714	Remove (tm)wiki from search results
Item1717	class foswikiTopicText missing in WebCreateNewTopicTemplate and TopicDoesNotExistViewTemplate
Item1718	Hex values in topic form fields are misread as anchors
Item1722	FORMFIELD documentation is difficult to understand and there is an error in the example
Item1725	Oops: we could not recognize you truncated in French language
Item1726	CALC in EditTablePlugin causes errors during editing
Item1730	initPlugin does not get the $installWeb if $NO_PREFS_IN_TOPIC = 1
Item1732	EXTENSIONS.pm uses {version} without checking if it's undef
Item1738	Better line heights when font tag is used
Item1739	Prevent js error in edit screen
Item1752	PROXY is inadequately documented
Item3212	Rcs Lite can't recover from damaged version histories
Item5391	Dragging corners of table removes TML markup
Item8141	Variables/classes called old name in doc typo
Item8173	TablePlugin does not understand standard date formats
Item8184	Fix link to UserCommentsTemplate
Item886	Add footer parameter to SEARCH
Item1095	EditTablePlugin: Hide ugly long CALC when editing replaced by static text CALC
Item1568	Synchronise form submits with sessions to enhance further security against CSRF
Item1595	Add feature AddNumberOfTopicsToFormattedSearch to 1.0.6 and 1.1.0
Item1710	New standard escapes $lt, $gt and $amp to be used in SEARCH
Item5628	it would be useful if there was a version check in the wysiwyg JS

The Foswiki.org site is our only real face to the world. Showing an old buggy version gives a completely wrong impression of what we really offer for download.

I cannot express how happy I am that the site is finally on 1.0.6. And I know I am not alone.

And how happy I am that the site is now setup in a way that I know how to later upgrade it to 1.0.7. It will not take many days after the 1.0.7 release before the site will be upgraded now. And I can now be part of it because the site is setup in a standard documented way.

Comparing the number of SVN checkins from you KwangErnLiew and the checkins from ArthurClemens I do not think you have any right to critisize that he has not yet fixed PersonalInfoAddOn. It is a minor luxory feature. It is much more important that Arthur has made a significant effort on the foswiki site skin and that he has fixed a looooong list of severe business affecting bugs in EditTablePlugin and TablePlugin. And last not least he never stopped maintaining and improving PatternSkin. And in 1.1 his contributions on the new configure will be very visible to the end user. Arthur knows about the PersonalInfoAddOn bug. He has just given it lower priority. The policy for it does not stop anyone else from stepping in and fixing it.

And I can say similar things about many other contributors that have had significant impact on the many extensions we offer and to the core code. Yes even Olivier who I have argued with in this topic has been a significant contributor to the core code and a huge help around the clock on the last nights before a release. We cannot do everything we want. We have to prioritize.

I am sure that now the site is on 1.0.6 the PersonalInfoAddOn will become a visible dot on Arthur's radar.

-- KennethLavrsen - 16 Sep 2009

Once again, you totally miss my point.

My point is: where we are now with this 1.0.6 release is where I left test.foswiki.org 3 months ago. Why didn't you then provide moral support so I dared make the switch and we would have dealt with glitches afterwards? No, I don't take it personal.

As a side-note, the System web still looks a bit dodgy to me, but maybe it's not worth caring. The main point of the release branch was exactly that: there are things you have to merge when you upgrade. And it's much easier to merge using a tool designed for it (like subversion, git, svk, whatever you like), than doing some diff on the command line or some other hacked method.

When I did almost the same job Koen did (that is bring test.foswiki.org to almost the same level six.foswiki.org was), very few people commented, and the few comments we had were about this PersonalInfoAddOn not working, therefore we halted and waited. If I remember correctly, Arthur said at the time he's look into it. As he's been very busy we other things (we all were), this plugin never got fixed. In fact, the main issue is that the way to fix it isn't completely clear (it needs to call 2 things upon save, which could be triggered by an onSave handler, but it would most likely trigger the CSRF or XSS protection, as in fact, that's what the plugin does (edit a topic when you save another one)).

So in brief:

• I take full blame for not having upgraded the site sooner using the foswiki.org branch. I didn't dare, and I have loads on my plate at work (changing jobs), therefore I had no time for it.
• I'm very happy the site has been upgraded to 1.0.6, even though it's using tarball
• I'll be glad to document and explain the pros and cons of using a branch versus using a tarball
• Kudos to Koen for taking the time to upgrade, and daring doing so

That said, I think we can wait for 1.0.7 to be released before closing this bug.

-- OlivierRaginel - 16 Sep 2009

Set waiting for Olivier, as it looks like although we're running latest release, some loose ends still need tidying up

-- PaulHarvey - 24 Mar 2010

Yeah, we didn't have much time to document this, and it seems people don't like it. I'd rather wait for us to migrate to some decent VCS and then do it again.

Closing this bug, and removing the foswiki.org branch from the git mirrors.

-- OlivierRaginel - 24 Mar 2010