• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Bugs web is more often broken than working.

The self-repair script which in itself is a terrible is today my most often used short cut in my browser. It is a terrible hack which should only be necessary to use maybe once per month.

Recently the ~twiki4 bugs is so broken that not even the self repair script can bring it back on its feet.

People discuss little details like how the download page on TWiki.org looks like and arguments about bad impression comes up if someone adds a hotfix to the download topic. And at the same time we have allowed our bugs web to look like shit for months and months.

Most of ours current and potential users are met with a bugs web which has a half working skin, error messages about no top bar and left bar which makes navigation close to impossible, or the menu bar hanging below the topic and horror colours and other types of uglyness and missing features.

When I started using bugs it worked and got updated fine from SVN.

I myself run a test server which updates from a SVN checkout every 30 minutes. And this runs fine too.

It was when the automation of SVN checkins added to the bug items was added to the SVN hooks that the real trouble began.

Bugs is part of TWiki's face to the world and it is not a pretty face.

Bugs was also supposed to be a test bed so people could see if they broke something. This purpose is completely missed because you always assume that bugs web looking bad is because of the update problem and not because of your code ot skin change.

So I propose that we install 4.0.3 staticly without any updating as our bugs web and have two other test twikis running in parallel: One for DEVELOP and one for TWIKI4 branch.

The SVN checkin hooks will then hit a static version of TWiki which then cannot break during pseudo-install.

And the two test sites will be simple SVN checkout/pseudo install trees that cannot be goofed up by what is clearly a race condition with the SVN stuff.

The BUGS web on 4.0.3 then becomes a nice looking stable bugs application. And the two test environments will work most of the time except then the code itself is broken.

From the Bugs web left bar we can link to webs in both the DEVELOP and TWIKI4 test environments so people can add their "reproduction test cases" there when they need to demonstrate a bug found on current SVN version of either DEVELOP or TWIKI4.

Implementation of this is easy.

  • Bugs application: Install 4.0.3 and copy the Bugs web to it and change a few left bar links. SVN checkin hooks manipulate only this twiki
  • twiki4/develop: are updated by simple cron job that does the steps of this example below (this is what works for me)

#!/bin/sh
cd /usr/local/apache2/twiki4
rm `find . -type l -print`
svn update
perl pseudo-install.pl -link default
cd ..
chown -R apache:apache twiki4

I hope those few with root access to bugs will find the time to implement this.

KJL

I am directing quite a few requests in TWiki:Support.WebHome to here at the moment, so I would also appreciate it if the Bugs interwikilink from t.o. pointed to something "stable" (to avoid scaring too many users off unnecessarily).

Both ~twiki4 and ~develop has their rights, so let's keep them as is and consider something like ~twiki403 (or simply ~latestrelease) for the public face.

-- SP

Curious. I use Bugs web every day, and I haven't seen it "broken" for a long, long time. i am constantly checking in, as well, so it's not just that the server isn't being updated.

I have no problem with running a server on 4.0.3 - it is trivial to set up - but the whole point of the bugs web was to act as a test platform. You are asking that we throw away all that test resource. Is that really a good idea?

CC

I think I run selfrepair ~once daily for ~develop currently (I don't use ~twiki4 that much). Perhaps the apache log can give an impression how large the problem is?

Alternatively, perhaps disable the selfrepair script temporarily and see to what extent it can stand on it's own legs for now?

-- SP

I also use the self repair 1-2 times per day. Especially the ~twiki4 branch has been totally broken the past 2 days. I can see it is finally up again.

I run my Firefox RSS (Sage) from ~twiki4 and my normal bookmark for ~develop is in my IE so I see both versions daily.

If both Steffen and I kick self-repair once per day and a few others do the same then it is several hours per day that it is broken. And as a test bed it is worth nothing if any little artifact is believed to be the pseudo-install that was incomplete. So I would say - let us run bugs on 4.0.3. We also need it to verify that a stock 4.0.3 has a the problem. Most developers run an SVN checkout anyway for testing.

And naturally keep ~develop and ~twiki4 for testing. We can even symlink the bugs web into them so the regular developers can choose to run bugs from them.

-- KJL

Time is 21:08 UTC and Bugs is again broken both on ~develop and ~twiki4. This is the 2nd time today that I experience it. I will start registering each time I see it since it seems not all believe me when I say it is broken all the time.

Screen shot from develop webhome attached.

Self repair works on ~develop but not on ~twiki4. It continues to look like....

-- KJL

I want to fix this properly, instead of ignoring the problem and installing 4.0.3. Could you please note here a description of exactly what was wrong whenever you have to run selfrepair please? The logs suggest that nothing is wrong with either installation, and that the pseudo-install is running fine. So I have to narrow this down; is it just a problem with the skin? Are you seening fatal errors? Thanks.

CC

Re Crawford's earlier comment: Kenneth isn't suggesting we do away with the test platforms, but that we move the Bugs web to something a little more stable. I agree with his suggestion to move Bugs to 4.0.3 and while still maintaining ~twiki4 and ~develop test installations.

I'm not familiar with how develop.twiki.org works, but it appears that both ~twiki4 and ~develop share the same data. Could this also be done with 4.0.3 to avoid losing any potential test material? For example: ~twiki403 would be the new location the Interwiki link would point, providing a stable entrance while leaving a full TWiki app (the Bugs web itself) available to ~develop and ~twiki4 for testing.

Just my $0.02 smile

-- JSH

When the error occurs, ~develop looks like no plugins/skins are installed. I will paste the output from selfrepair the next times I run it - usually it links the default plugins set, but sometimes it is just a few files that are not linked.

Perhaps selfrepair could write/tee/print its output to a log file where we can trace its doings (not that I mind pasting at all).

-- SP

I just looked up bugs again and it was broken as usual.

It is always the same.

It is pseudo-install that does not complete the work.

So usually all links to twikiplugins/PattenSkin are not there. I can see that because I know what the URLs should be to CSS and .js files and I cannot see any of them. Topics such as WebLeftBar and WebTopBar not to be found either. So you end up with naked skin which is not classic and not Pattern but just naked non-styled HTML with the left bar below the main content.

I have captured the selfrepair output and attached it.

I have also attached some screen shots from ~twiki4. Note that Firefox caches the files even if they are not available so you do not notice that bugs is broken if you have looked at it while it worked recently. Only left, top and bottom bars are missing then.

If you then clear the cache the page looses all graphics and CSS styles.

IE when setup to check if files have changed every time (which you have to when you run an application like TWiki) will only use cache if the server says the file is still there. So in IE Bugs look totally awful in IE the minute it is broken.

But the left/top/bottom bars are missing no matter of the cache is used or not.

~develop selfrepair works. ~twiki4 selfrepair returns a blank screen and does not repair anything.

-- KJL

Bugs ~develop is broken 02 Jul 2006 at 21:36 UTC. ~twiki4 was broken this morning and yesterday.

-- KJL

aye, see my email to twiki-dev - i agree I'm thinking three interfaces to the same topic data

  • bugs.twiki.org for users
  • develop.twikiorg as curring edge, maybe read only?
  • main.twiki.org as what we are working on for next release - ooo, what happened to the svn branch rename?

i'll get onto it

-- SD


Develop is retired. ~twiki4 seems pretty stable, and only goes grotty when there are a lot of checkins; but it's an invaluable test resource. Discarding.

CC

~twiki4 has had a broken PatternSkin for a week now. Some have had problems logging in. And in the future there will be more checkins that break things.

Another issue is that normal people report bugs to the latest production release. Not Twiki4.

So I would like to have this re-considered.

I propose that we run bugs on both the latest production version. And to keep it very stable we can make the svn updates and pseudo installs very rare or even manually triggered via a URL.

  • We have a stable bug reporting tool.
  • We have a test bed to verify bugs and reporters can create test cases that are relevant to the actual bug. And we can in a split second see if it is fixed in MAIN by looking at ~twiki4.
  • We keep the ~twiki4 running on MAIN and developers - if they are smart and have brains - run by default on that.

I keep on saying that twiki.org is our face to the world. So is our bugs database that we ask users to use when they see bugs. And then it is embarrassing that they at the moment meet a functioning but visually broken bugs database with mysterious TwikiVariable and before that attachment twisties that are broken. And the face of TWiki also indirectly becomes the face of those many of you that are professionals and associate yourself with TWiki. Image is everything when you compete on a market with many to choose from.

Renamed the bug report to reflect the current versions but the original intention is the same so that is why I did not open a new report. And changed priority to normal as this is not a release blocker.

I know at least one of you will want to discard this 2 minutes after I save it but please leave it open for debate a few days. I will want to bring it up at a release meeting anyway.

KJL

Kenneth, this is exactly the reason we run the bugbase off subversion. It is the only way we can be sure the code is getting tested! if there is a separate testbed it will be enthusiastically adopted for a few days, but ignored thereafter. Only by pushing bugs "in your face" are people motivated to fix the damn things!

If you think it looks bad, then please either fix the problems or push those responsible to fix them. I can't support anything that appears to be "brushing problems under the carpet".

CC

ItemTemplate
Summary Please run Bugs web also on 4.0.4 because bugs is often broken or an ugly piece of presentation
ReportedBy TWiki:Main.KennethLavrsen
Codebase ~twiki4
SVN Range Sun, 25 Jun 2006 build 10720
AppliesTo Engine
Component BugDatabase
Priority Normal
CurrentState No Action Required
WaitingFor

Checkins

TargetRelease n/a
Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng brokenbugs-060628-2116.png r1 manage 160.7 K 2006-06-28 - 19:24 KennethLavrsen  
Unknown file formatext selfrepair-output-txt r1 manage 9.8 K 2006-06-29 - 19:16 KennethLavrsen  
PNGpng twiki4broken-cache-cleared-bottom.png r1 manage 103.9 K 2006-06-29 - 19:25 KennethLavrsen twiki4 broken and FF cache has been cleared before reload bottom part
PNGpng twiki4broken-cache-cleared.png r1 manage 138.6 K 2006-06-29 - 19:24 KennethLavrsen twiki4 broken and FF cache has been cleared before reload
PNGpng twiki4broken-cashed.png r1 manage 205.6 K 2006-06-29 - 19:23 KennethLavrsen twiki4 broken but FF has cached the graphics
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2006-09-30 - CrawfordCurrie
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback