[09:54] *** Initial topic: 
bin/view/Codev/FreetownReleaseMeeting2007x02x12
[09:54] *** #twiki_release: PeterThoeny SvenDowideit1 SvenDowideit_ 
[09:54] *** #twiki_release was created on Sun Feb 11 20:39:31 2007.
[10:34] *** CDot has joined #twiki_release.
[10:35] *** WikiRingBot has joined #twiki_release.
[10:36] *** MichaelDaum has joined #twiki_release.
[10:46] *** WikiRingBot has signed off IRC (Remote closed the connection).
[10:46] *** WikiRingBot has joined #twiki_release.
[12:19] *** MichaelDaum is now known as MichaelDaum_.
[12:27] *** Flenser has joined #twiki_release.
[12:58] *** ArthurClemens has joined #twiki_release.
[13:02] PeterThoeny: hi arthur, craford, micha, sven!
[13:02] CDot: hi
[13:02] PeterThoeny: s/craford/crawford/ (sorry)
[13:02] PeterThoeny: who is WikiRingBot?
[13:02] *** WikiRingBot is n=micha@wikiring.de (WikiRingBot)
[13:02] *** WikiRingBot is on: #twiki #twiki_release 
[13:02] *** WikiRingBot is using irc.freenode.net http://freenode.net/
[13:02] *** End of /WHOIS.
[13:02] ArthurClemens: good evening
[13:03] CDot: its a logger
[13:03] ArthurClemens: I am just testing out a new IRC client (Mac)
[13:03] *** Lavr_ has joined #twiki_release.
[13:03] PeterThoeny: that means we can't discuss anything that should not be logged?
[13:04] CDot: no, the logs are private
[13:04] ArthurClemens: it has been deployed in eastern europe before
[13:04] ArthurClemens: WarschauRingBot
[13:05] PeterThoeny: private to who?
[13:05] CDot: to me, micha, sven, lynnwood
[13:05] PeterThoeny: ok
[13:06] PeterThoeny: hi kenneth!
[13:06] PeterThoeny: i think we have critical mass to start!
[13:06] PeterThoeny: we are getting better in time
[13:07] PeterThoeny: who is taking the minutes, who is facilitating?
[13:07] Lavr_: Maybe whoever put this bot thing want to use it for the minutes?
[13:08] ArthurClemens: if it doesn't crash?
[13:08] PeterThoeny: well, actually, a manual copy paste is more appropriate in case 
we have something that should not be logged
[13:08] PeterThoeny: (unlikely though)
[13:09] CDot: im happy to turn it off
[13:09] PeterThoeny: i take the facilitator role unless someone would like to do it
[13:10] PeterThoeny: kenneth, do you want to take the minutes?
[13:10] ArthurClemens: I can do the copy paste
[13:10] Lavr_: OK
[13:10] ArthurClemens: who!?
[13:10] PeterThoeny: and arthur the copy paste, thanks
[13:10] PeterThoeny: kenneth: minutes text, arthur: attach log as i understand
[13:10] ArthurClemens: I have until 22:30 GMT
[13:11] PeterThoeny: proposed agenda:
 # 1. TWiki Release 4.1.2 Coordination
 # 2. TWiki 4.1 Post Mortem Discussion
[13:11] ArthurClemens: but I can leave the app open if not finished
[13:11] PeterThoeny: anything to add?
[13:12] ArthurClemens: Will we discuss any features?
[13:12] PeterThoeny: ok, lets start with:
[13:12] PeterThoeny: ---+ 1. TWiki Release 4.1.2 Coordination
[13:12] PeterThoeny: 
http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/AllOutStandingItems?class=.*;=&sortcol=3;table=1;up=1#sorted_table
[13:13] PeterThoeny: we have a number of release blockers
[13:13] PeterThoeny: should be quickly glance over them?
[13:13] Lavr_: I am happy to see that the regular developers have administered well 
what should go into Patch04x01 and what should go only yo MAIN
[13:13] PeterThoeny: yes, that works now well
[13:13] PeterThoeny: Item3573 - Fatal Error Creating Wiki Group (Windows 2003)
[13:14] PeterThoeny: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3573
[13:14] PeterThoeny: this is a release blocker for those who are affected
[13:14] PeterThoeny: but i think it should not block the release for more urgent cases
[13:14] Lavr_: Has anyone reproduced it besides the reporter?
[13:14] PeterThoeny: CDot, you seem to be on top of this item?
[13:15] CDot: on phone sorry
[13:15] Lavr_: (I have been unable to reproduce it myself) 
[13:16] Lavr_: is CDots last words
[13:16] Lavr_: Seems like the bug is on top of us more than us on top of the bug
[13:16] Lavr_: I do not have a TWiki on Windows either
[13:17] PeterThoeny: reported at
 http://twiki.org/cgi-bin/view/Support/FatalErrorCreatingWikiGroup 
 http://twiki.org/cgi-bin/view/Support/ErrorWhenLoadingGROUPSVariable
[13:17] PeterThoeny: by two persons
[13:18] PeterThoeny: next one:
[13:18] PeterThoeny: Item3615 - Sometimes large pages get truncated after save or preview
[13:18] PeterThoeny: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3615
[13:18] PeterThoeny: this is new, needs to be investiagted more
[13:18] Lavr_: That is a Speedy_CGI problem. And it is NOT new.
[13:18] CDot: I was hoping that someone else would have installed on Windows by now
[13:18] PeterThoeny: also not a release blocker i think
[13:18] Lavr_: It is exactly what you were fighting on twiki.org
[13:19] CDot: but it appears I am the only TWiki dev with a Windows box?
[13:19] PeterThoeny: so lets reprio this to normal
[13:19] ArthurClemens: I have a WIndows down, but never installed TWiki on it. I don't 
know Windows that good.
[13:20] PeterThoeny: i only have twiki for windows personal running
[13:20] CDot: I don;t even know if it's specific to windows
[13:21] PeterThoeny: a code walk throught might reveil the cause
[13:21] CDot: perhaps
[13:21] ArthurClemens: code walk?
[13:22] PeterThoeny: code review
[13:22] Lavr_: It would be nice if the reporters would give us the Apache error_logs. 
They only give the TWiki log.
[13:22] Lavr_: Item3615 there is no log at all
[13:23] Lavr_: Item3615 is for sure the same we saw on TWiki.org where topics got 
truncated also.
[13:23] PeterThoeny: kenneth: i added a note accordingly to the bug item
[13:24] Lavr_: For Item3615 we also need to know which plugins he runs and he needs to 
try turning them off one by one to see if it is a plugin related issue
[13:24] Lavr_: His configure html shows several non-standard plugins
[13:25] PeterThoeny: could you add the notes to the bug item?
[13:25] Lavr_: OK
[13:25] CDot: unlikely; I'm betting on a resource issue in the server, killing the 
process before the page is complete
[13:25] CDot: that seems to be what happens with poorly-tuned speedy cgis
[13:26] PeterThoeny: next:
[13:26] PeterThoeny: Item3582 - Page loads unreasonable slow under IE with Twisty enabled 
 http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3582
[13:26] ArthurClemens: yes, I have to look into that
[13:26] Lavr_: Worst case we remove the twisty for attachments.
[13:26] PeterThoeny: thanks arthur
[13:27] PeterThoeny: anything that should be discussed here on this item?
[13:27] ArthurClemens: that would be a bad solution
[13:27] ArthurClemens: not at this time
[13:27] PeterThoeny: i actually would prefer to have the twisty removed from attachment 
table
[13:27] ArthurClemens: but I can work on it only after 25 Feb
[13:27] PeterThoeny: for better usability
[13:27] Lavr_: But it would be a necessary solution of the problem is not solved because 
it is really a showstopper issue
[13:28] PeterThoeny: i find it too complex to have two layers of hiding content: 
individual attachments with hide attribute, and whole table with twisty
[13:28] ArthurClemens: usability: it really depends on the circumstances
[13:28] ArthurClemens: on our intranet a lot of files are just there for archival
[13:28] PeterThoeny: agreed, there are use cases where it makes sense, but i think those 
are rare
[13:29] ArthurClemens: on twiki.org they are part of the discussions and proposals
[13:29] ArthurClemens: why rare?
[13:29] CDot: I would certainly value some instruction on turning the twisty off
[13:29] PeterThoeny: because people already decide if the uoloaded file is visible or 
hidden at the time of upload
[13:29] CDot: several of my clients have complained about it
[13:29] PeterThoeny: so, only important files are shown
[13:30] Lavr_: I have also removed it from both my Motion and Motorola sites.
[13:30] PeterThoeny: we have removed it from twiki.org
[13:30] PeterThoeny: but it got back on twiki engine upgrade
[13:30] PeterThoeny: i want to remove it again from twiki.org
[13:30] PeterThoeny: and ideally also in the distro
[13:31] PeterThoeny: with note how to enable this?
[13:31] ArthurClemens: I believe it is confluence that has an ajax interface for the 
attachments
[13:32] CDot: not a bad idea
[13:32] ArthurClemens: its principally the same kind of experience, except that it 
is always hidden at start
[13:32] Lavr_: Hidden at start - even worse.
[13:32] ArthurClemens: yes
[13:33] ArthurClemens: I agree that a manual for easy removal (or easy adding) would 
be welcome
[13:33] PeterThoeny: it is also hidden at start in the default twiki (not good)
[13:33] ArthurClemens: it shouldn't be
[13:33] ArthurClemens: depends on your cookie setting
[13:33] PeterThoeny: when i visit a new twiki site for the first time i see it hidden 
(if i recall correctly)
[13:34] Lavr_: The user does not know that he sets/resets a cookie. He is just confused 
that sometimes it is hidden and sometimes it is not
[13:34] ArthurClemens: it is just like a personal dashboard
[13:34] ArthurClemens: if you close an item it will be stored
[13:35] ArthurClemens: this is a common interface
[13:35] PeterThoeny: arthur: would this be acceptable to you to remove the twisty and 
to add a cookbook on how to add it?
[13:35] PeterThoeny: or do you prefer it the other way around?
[13:35] ArthurClemens: that's ok
[13:35] ArthurClemens: noting the temperature here
[13:36] PeterThoeny: ok, in this case do we have a consensus to remove the attach 
twikisty, with note how to add it?
[13:36] PeterThoeny: please voice "yes" or "no"
[13:36] ArthurClemens: (note that often it might be the visibility of the opening button)
[13:36] ArthurClemens: (if that is really visible, there is less of a problem)
[13:37] ArthurClemens: (so people notice a UI problem, but the problem lies in fact 
elsewhere)
[13:37] Lavr_: I want people to see the attachments if they are not hidden. If I want to 
hide them I hide them for real.
[13:37] PeterThoeny: same here
[13:38] PeterThoeny: kiss
[13:38] ArthurClemens: often it is page clutter
[13:38] ArthurClemens: and it does not add value to the topic
[13:38] PeterThoeny: it does not if you have links to the attachments in the topic
[13:38] Lavr_: What we lack is a bulk hide/unhide feature in "manage" attachments. 
It is a pain to hide 15 attachments.
[13:38] PeterThoeny: this can be controlled at the time of upload
[13:39] PeterThoeny: kenneth: that is a very good idea!
[13:39] ArthurClemens: no, that is the responsibility of the adder
[13:39] ArthurClemens: not of the viewer
[13:39] PeterThoeny: yes, add checkboxes to the attachments in manage screen to do 
bulk operation: hide/unhide, move
[13:40] ArthurClemens: http://twiki.org/cgi-bin/view/Codev/ImproveAttachmentHandling
[13:40] PeterThoeny: i think this needs more discusson
[13:40] Lavr_: But that would be 4.2
[13:40] PeterThoeny: lets park it
[13:41] ArthurClemens: I think we can continue
[13:41] PeterThoeny: for 4.1.2 i suggest to fix the speed issue, and if not possible, 
to remove the attach twisty
[13:41] PeterThoeny: Item3568 - Not all Linuxes allows TWiki to create a /tmp/twiki 
 http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3568
[13:41] Lavr_: I have been looking at what the difference is when the /tmp/twiki is 
created and when it is not.
[13:42] Lavr_: And it seems to be CGI::Session version dependent.
[13:43] Lavr_: My Motion server is a Fedora Core 5 which has 3.95. It fails to create. 
The two servers I develop on has 4.X CGI::Session.
[13:43] Lavr_: I would really like TWiki to auto create the directory to make ONE less 
hurdle for the installer. But not at the expense of speed.
[13:43] PeterThoeny: is it possible to create the directory if session fails, then try 
again?
[13:44] Lavr_: I was thinking along that path.
[13:45] Lavr_: As Patch04x01 works now with the latest changes to configure - configure 
will show an error if /tmp/twiki is not there. So we could ship tomorrow with that.
[13:45] Lavr_: But I would like to additionally see TWiki auto create it.
[13:45] PeterThoeny: yes, agreed
[13:45] CDot: disagree, for the reasons I gave in the report
[13:46] Lavr_: Auto creating also makes it easier for the non-root installers.
[13:46] CDot: more unneccessary code cruft
[13:46] PeterThoeny: non-root installs have no way to make this directory secure
[13:46] CDot: use configure to do that job if you must
[13:46] ArthurClemens: just a second
[13:46] PeterThoeny: unless auto-created
[13:47] PeterThoeny: crawford, what is the reason you do not like it auto-created?
[13:47] CDot: if it is created by configure, then it's exactly the same as if it was 
created by the view process
[13:47] Lavr_: We already has a guy with a problem installing a directory owned by 
Apache on a shared host and Peter proposing an awful (but working) work around.
[13:47] PeterThoeny: (yes, that is a hack)
[13:47] CDot: because of the cost of the -d, the difficulty of error reporting, the 
"post-configure gotcha" syndrome it implies
[13:47] Lavr_: Letting configure create it could also work BUT it does not help when 
you boot and have a machine that wipes /tmp.
[13:47] PeterThoeny: (dangerous one if script is left on the server)
[13:48] CDot: Lavr_: it's no problem if we move the default away from /tmp
[13:48] CDot: it's a bad place anyway, for the reasons you pointed out
[13:48] CDot: I always use a "sessions" subdir under the root of the install
[13:49] Lavr_: And when people put twiki in htdocs or cgi-bin?
[13:49] PeterThoeny: on cost of -d: it can be avoided by assuming it is there, and 
take action only if a file action fails
[13:49] Lavr_: CGI::Session 4.X already autocreates the directory. It is just the 3.X 
case we need to handle.
[13:50] Lavr_: Cannot say exactly which version that it starts autocreating under.
[13:50] CDot: all the more reason to do it in configure, and avoid burdening the core
[13:50] Lavr_: Obviously the CGI::Session guys must have added that for a good reason.
[13:50] PeterThoeny: kenneth is on top of this item, and we can ship the partial fix in 
4.1.2 if needed
[13:51] Lavr_: CDot. What about when you boot? A power out?  THen you need to run 
configure again. Yuk.
[13:51] PeterThoeny: i also think it is not good to rely on configure to autocreate stuff
[13:51] PeterThoeny: windows xp is self healing
[13:51] PeterThoeny: why not twiki?
[13:52] Lavr_: It is quite normal for CGI programs to place session files in /tmp and 
obviously the CGI::Session guys have added the dir create feature for a good reason.
[13:52] Lavr_: It is the CGI flush function that fails always. I bet we can react on an 
error from that and create the dir and flush again.
[13:53] Lavr_: Should be 2-3 code lines that only runs when the dir is not there.
[13:53] ArthurClemens: back
[13:53] PeterThoeny: sounds like a reasonable approach
[13:53] PeterThoeny: lets go to next item, imho the most pressing one for 4.1.2:
[13:54] PeterThoeny: Item3564 - TWiki should support Perl 5.0.3 
 http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3564
[13:54] Lavr_: But it is still important that also configure shows an error for 
when you want to use non tmp dir. So the configure behavour is OK.
[13:54] SvenDowideit_: morning
[13:54] PeterThoeny: hi sven
[13:54] Lavr_: On 5.5.3 perl. I found a virtual machine for VMWare with perl 5.5.3.
[13:54] SvenDowideit_: so? did you guys just decide to write some code for a broken 
old version of cgi?
[13:54] CDot: is anyone actually working on supporting Perl 5.0.3?
[13:54] PeterThoeny: i think all are up to date on the 5.0.3 / 5.6.5 / 5.8 question
[13:54] SvenDowideit_: while it works ok for the current version of CGI?
[13:55] Lavr_: No Sven not the broken version. 3.95 is not a broken version AFAIK 
[13:55] SvenDowideit_: i'd call non-autocreating the session dir a bug
[13:55] PeterThoeny: perl 5.0.3 is a very stable version
[13:56] SvenDowideit_: and as a newer version of CGI fixes that
[13:57] PeterThoeny: ok, most urgent for 4.1.2 is perl 5.6.5 support, as it was up to 
twiki 4.0.5
[13:57] Lavr_: The VM I have is a RedHat 6.2 which has CGI 5.5.3
[13:57] PeterThoeny: so, we can try to attack both, support for 5.0.3 and 5.6.5, but 
with priority on 5.6.5
[13:57] Lavr_: The problem with the 5.5.3 is to find and install CPAN libs for it.
[13:58] Lavr_: I tried to install File::Temp the CPAN way and it failed.
[13:58] Lavr_: After some experiments CPAN started to install perl 5.8 and after 2 
hours it crashed.
[13:58] PeterThoeny: ouch
[13:58] Lavr_: So how do you install CPAN libs on an old 5.5.3?
[13:59] PeterThoeny: probably needs a cpan install from a cd of that time
[13:59] PeterThoeny: anyway, it is probably difficult to get twiki running on 5.0.3, and 
easy to get it running on 5.6.5
[13:59] Lavr_: To get a RedHat with 5.6 perl you need RH 7.3. I have downloaded it but not 
yet installed a VM with it. I could not find a prefab VM with RH73
[14:01] Lavr_: I tried to run configure under 5.5.3. First thing is "use warnings" is not 
supported. Next thing is File::Spec is too old. That is where I stranded.
[14:01] PeterThoeny: +60 min
[14:01] ArthurClemens: 30 min left for me
[14:02] Lavr_: I think we should start with 5.6.X and forget 5.5.3. It is too old.
[14:02] PeterThoeny: on file::spec too old, this might just be a wrong requirement
[14:02] Lavr_: No. It was a missing feature in File::Spec
[14:02] PeterThoeny: ah, so possibly not use that new feature then
[14:02] Lavr_: File::Spec was version 0.5 or something like that in 5.5.3
[14:03] CDot: while I'm keen on the idea of you working to support older perls, I'm 
concerned about our ability to run regressions on the older platforms
[14:03] PeterThoeny: yes, focus first on 5.6.5 is a sensible thing
[14:03] CDot: do we now have test platforms availbel for testing releases?
[14:03] Lavr_: I think most of the reporters of trouble have been trying on 5.6.X.
[14:04] PeterThoeny: i think that was the idea of will's tinderbox
[14:04] Lavr_: CDot. It is what I am trying to create with a VM.
[14:04] PeterThoeny: yes, the vm approach is a good one
[14:04] CDot: ok; on active state perl as well?
[14:04] CDot: what about older apache versions? e.g Apache 1.3 is common
[14:05] CDot: it;s only a matter of time before we do womething that isn't compatible...
[14:05] CDot: and we need the test platforms in place
[14:05] Lavr_: I believe the RH 7.3 will use Apache 1.3 and Perl 5.6. So limiting the 
support of older version to that may be OK.
[14:06] CDot: ok, so the claim becomes "tested on perl 5.8 and Apache 2 and Perl 5.6 
and Apache 1.3"?
[14:06] PeterThoeny: that is the right thinking, build up a test infra where we can test 
twiki on various oses, apache versions and perl versions
[14:06] Lavr_: I think Windows users have an easier time upgrading their perl. It is the 
shared hosts and people forced to using some older Sun server that has the problem.
[14:06] CDot: oh right; operating systems. That's another can of worms.
[14:07] CDot: Solaris has been a consistent source of problems
[14:07] CDot: centos not far behind it
[14:07] PeterThoeny: and the many inexperienced prospects trying to install and use twiki 
(THAT is the biggest problem we need to solve)
[14:08] PeterThoeny: we are not gaining market share as quickly as we could as long as we 
do not solve the out-of-box experience
[14:08] SvenDowideit_: happily, there seem to be very few issues on debian anymore :p
[14:08] CDot: I'm fully supportive of getting it running on older platforms; I just want 
to understand the scope of the problem
[14:08] CDot: and what the plan is to address that scope
[14:09] SvenDowideit_: wouldn't it be better to start with current systems?
[14:09] CDot: because attacking it piecemeal isn;t going to work
[14:09] PeterThoeny: asking a person who never heard of perl and cpan to upgrade perl 
or install cpan modules is a bit daunting
[14:09] SvenDowideit_: and move to the older perls & os's when we're done?
[14:09] Lavr_: Fact is we cannot test all. So we have to go for the high runners. And 
a test bed with Apache 1.3 and a Perl 5.6 to supplement the A2/P5.8 we all have may be 
not too bad.
[14:09] CDot: Lavr_: yes, that is a big win
[14:10] PeterThoeny: that is a good first step
[14:10] CDot: however I know that many CPAN modules have specific versions that just 
don;t work with 5.6.1
[14:10] ArthurClemens: as ignorant user I actually find cpan very easy to use, once you 
know to type 'cpan'
[14:11] PeterThoeny: arthur: you are an expert compared to the average person who tries 
to install twiki
[14:11] PeterThoeny: we are all experts compared to them (in average)
[14:11] PeterThoeny: it is easy to forget this because we are geeks among geeks
[14:12] CDot: I don't understand the resistance to using simple installers
[14:12] CDot: perl version aside, CPAN modules can be upgraded almost invisibly
[14:12] CDot: and installed locally in hosted environments
[14:13] PeterThoeny: anything that automates the install in a secure way is good
[14:13] PeterThoeny: (if it works on many major platforms that is)
[14:13] CDot: then why am I the only person working on it for the last 3 years?
[14:14] ArthurClemens: you are the only person working on twiki for the last 3 years
[14:14] CDot: heh
[14:14] ArthurClemens: I love installers
[14:14] Lavr_: We all love installers. When they work!
[14:15] PeterThoeny: fool prove installers are good
[14:15] ArthurClemens: it has been said: if there is going to be an installer, there 
must be a Windows installer as well
[14:15] PeterThoeny: the challenge is to write a solid installer that works in all env
[14:15] Lavr_: Problem with fool proof is that fools are so inventive.
[14:15] ArthurClemens: like TWiki is fool proof?
[14:16] PeterThoeny: s/fool/geek/ at the moment :-)
[14:16] Lavr_: I think the first step is to realize the same as other major programs. 
You need one installer for Windows and another for Linux/Unix.
[14:17] PeterThoeny: good point
[14:17] PeterThoeny: good discussion; we are drifting from the subject
[14:18] PeterThoeny: so, shall we focus on making twiki 4.1 work on perl 5.6.5 as 
quickly as possible so that we can release 4.1.2 as quickly as possible to solve the 
out-of-box experience question?
[14:19] Lavr_: To round off the Item3564. I will continue trying to create a VM of RH7.3. 
That is my next step on that. Time will tell If I can make that work.
[14:19] PeterThoeny: nice, thanks kenneth!
[14:19] PeterThoeny: moving on:
[14:19] PeterThoeny: Item3555 - Update of release note and install docs for 4.1.1
[14:19] PeterThoeny: no need to discuss, just a reminder
[14:20] PeterThoeny: Item2960 - using utf8 breaks headline anchors 
 http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2960
[14:21] PeterThoeny: just reading this item
[14:21] ArthurClemens: not clear where that entry is going
[14:21] PeterThoeny: oh, i would be careful with changing anchor names, make sure to 
keep links compatible
[14:22] PeterThoeny: is this urgent or nomal prio?
[14:23] PeterThoeny: i think richard d needs to help on this
[14:23] Lavr_: The real issue seems bigger than a normal patch release type bug fix
[14:23] PeterThoeny: yes
[14:25] PeterThoeny: Item1742 - Support simultaneous edits in WysiwygPlugin 
 http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item1742
[14:25] PeterThoeny: what is the status on this one?
[14:25] PeterThoeny: is it urgent?
[14:25] Lavr_: It is marked for a major release.
[14:25] CDot: yes, but it's not going to get done any time soon
[14:25] Lavr_: Ie 5.0
[14:26] PeterThoeny: ok
[14:26] PeterThoeny: we are done with blocker review
[14:26] PeterThoeny: +86 min
[14:27] PeterThoeny: lets go to next agenda item
[14:27] PeterThoeny: ---+ 2. TWiki 4.1 Post Mortem Discussion
[14:27] Lavr_: From a top view. Is 4.1.2 an urgently needed release like 4.1.1 was 
or should we target it 2-4 weeks from now?
[14:28] PeterThoeny: for me, 4.1.2 is urgent mainly to fix the perl version problem
[14:28] PeterThoeny: so, release as soon as feasible
[14:28] Lavr_: THAT in itself seems like a 2-4 weeks from now release because it will 
take some effort setting up and test
[14:28] PeterThoeny: unfortunately, yes
[14:28] Lavr_: OK
[14:29] PeterThoeny: i find it very unfortunate that 4.1.x does not work on perl 5.6.x
[14:29] PeterThoeny: unfortunate for the success of the twiki project
[14:29] *** CDot has left #twiki_release.
[14:29] PeterThoeny: hence important
[14:30] PeterThoeny: ok, on to free form discussion
[14:30] PeterThoeny: +80 min
[14:30] PeterThoeny: shall we keep this to 30min?
[14:30] PeterThoeny: finish at +120min?
[14:30] Lavr_: yes
[14:30] PeterThoeny: all, anything goes
[14:31] PeterThoeny: what worked well, what did not work so well on twiki 4.1 release 
and its preparation
[14:31] PeterThoeny: ?
[14:31] Lavr_: On the release process. I think the customer advocate / 14 day rule 
worked well.
[14:31] PeterThoeny: yes
[14:31] Lavr_: But I would not want the customer advocate role alone again.
[14:32] Lavr_: And we need to setup a TWiki app to support it.
[14:32] PeterThoeny: we forgot to officially close the block on the 14 day rule shortly 
after the 4.1 release
[14:32] PeterThoeny: it is kind of implicit though
[14:32] PeterThoeny: but the topci was not updated until recently (to remove the block)
[14:33] PeterThoeny: yes, we need to tracker app
[14:33] PeterThoeny: not rocket science to create it
[14:33] Lavr_: No. And this process does require either a guy that keeps an eye on the 
topics or a good twiki app with a search that shows what needs to be taken up at release 
meeting
[14:33] PeterThoeny: actually to change the existing tracker
[14:34] PeterThoeny: xactly
[14:34] Lavr_: There are TWO manuall processes that require SOMEONE. ANYONE.  One is 
to evaluate that a proposal is not just a user proposal without a committed developer.
[14:34] PeterThoeny: hi Flenser/sam: are you here?
[14:35] Lavr_: And one is to evaluate if a long proposal has reached concensus and does 
not need release meeting decision.
[14:35] PeterThoeny: yes
[14:36] PeterThoeny: all: this is about 
http://twiki.org/cgi-bin/view/Codev/TWikiFeature04x02
[14:36] Lavr_: So we need the app to have a date flag for the 14 day rule. And we need 
a flag people can throw to flag "release meeting decision needed"
[14:36] PeterThoeny: i just realize that this topic is not very accessible
[14:36] PeterThoeny: let me add it to the sidebar
[14:36] PeterThoeny: of the codev web
[14:36] PeterThoeny: sam said that he will work on it
[14:36] PeterThoeny: Flenser: around?
[14:38] Lavr_: I am currently not up to speed on the topics on TWikiFeature04x02. The 
release manager stuff has taken all my available TWiki time + time I should have spent 
sleeping.
[14:38] PeterThoeny: what else on release process?
[14:39] Lavr_: Some practical things.
[14:39] PeterThoeny: (I added a "feature proposals" link to the sidebar)
[14:39] Lavr_: On testing we need to coordinate some beta testers. I had the 
impression that noone tested the betas.
[14:39] ArthurClemens: Lavr_: your topic with database proposal has gotten out of 
view
[14:40] Lavr_: THAT was a "start thinking looong term" topic mainly meant to trigger 
some long term idea instead of just thinking next minor or patch release.
[14:40] Lavr_: It is not a topic for TWikiFeature04x02
[14:41] ArthurClemens: of course
[14:41] Lavr_: What is needed for 4.2 or 5.0. It seems people see more a 4.2. .... is 
release theme(s)!
[14:42] Lavr_: But to round off 4.1.0/4.1.1
[14:42] Lavr_: So beta testing was not organised well enough.
[14:43] ArthurClemens: I don't think many people were testing
[14:43] PeterThoeny: any idea how we can improve the beta testing?
[14:43] PeterThoeny: i think more pr for beta testing would help
[14:44] PeterThoeny: somehow reach the people who are willing to help out testing a 
new version
[14:44] ArthurClemens: the developers were still fixing bugs
[14:44] Lavr_: We need to get some non-developers organized to download and test. And 
we need to tell them what they should look for so it becomes a task that takes a few 
hours instead of something that sounds like weeks of work.
[14:44] PeterThoeny: how about sending out an e-mail to twiki-announce at rc1 time to 
solicit testers?
[14:44] ArthurClemens: is it possible to create smaller subtasks?
[14:45] Lavr_: What I think a beta tester should do it....
[14:45] Lavr_: 1. Try to install it. THAT triggers the basic errors.
[14:45] Lavr_: 2. Try to run a few of their own webs on it and see how things work. 
That will find a lot of the bugs that came in the first week after release of 4.1.0
[14:46] PeterThoeny: yes, point 2 is important
[14:46] PeterThoeny: for compatibility check
[14:46] Lavr_: WE developers run test cases and unit tests. That is not what beta 
testers should try to do. They should just try to install it and run normal topics 
that they use every day
[14:47] PeterThoeny: so we should create a TWikiBetaTesting topic in codev
[14:47] ArthurClemens: and make it visible
[14:48] Lavr_: Yes. And I think we should approach some of the guys that often report 
bugs or ask support questions.
[14:48] PeterThoeny: with instructions for non developers how to download twiki, how 
to install (on same or different server as production twiki, using separate insatll 
tree, and sym-link data and pub to production data)
[14:48] ArthurClemens: I am leaving you now: bedtime
[14:48] ArthurClemens: shall I put the last part in the log as well?
[14:49] Lavr_: Make a list of the most 20 active users - not developers. Give them a 
chance to make a difference for the project with only a few hours of work.
[14:49] PeterThoeny: ArthurClemens: before tou leave
[14:49] PeterThoeny: quick question
[14:49] ArthurClemens: yes
[14:49] PeterThoeny: twiki.org has two sleeping nano processes owned by you 
[14:49] PeterThoeny: can i kill them?
[14:49] ArthurClemens: sure
[14:49] PeterThoeny: ok
[14:49] ArthurClemens: they must be months old
[14:50] PeterThoeny: thanks ArthurClemens, and good night!
[14:50] Lavr_: Good night Arthur
[14:50] ArthurClemens: night!
[14:51] *** ArthurClemens has left #twiki_release.
[14:51] Lavr_: Next item I have on post mortem is the last 1-2 weeks before release. 
That needs to be coordinated better so that the release manager gets a stable thing 
to release.
[14:51] PeterThoeny: let me create a placeholder topic for beta testers, for others 
to fill in teh details
[14:52] Lavr_: We saw quite many bugs created the last two weeks before releasing 
4.1.0 while fixing other bugs.
[14:53] Lavr_: From feature freeze we need to plan at least 4 weeks of bug fixing 
only.
[14:53] PeterThoeny: yes, we need time for bug fixing
[14:53] PeterThoeny: here is an idea from the ubuntu project
[14:53] Lavr_: I was negatively surprised by the number of very basic bugs we found 
the first week after 4.1.0
[14:53] PeterThoeny: they have a fixed release cycle every 6 month
[14:54] PeterThoeny: wind river is doing the same
[14:54] PeterThoeny: they call it release train
[14:54] PeterThoeny: new features make it or don't make it into a train (aka release) 
based on some criteria
[14:55] PeterThoeny: such as tested, integrated into regression tests etc
[14:56] Lavr_: Yes. We need something like this. Even if the releases are not a fixed 
interval we need to define criteria for T-1 week, T-4 weeks, T-8 weeks etc
[14:56] PeterThoeny: the many bugs in first week of 4.1.0 is due to the fact that we 
had not many outside beta testers and that we still need to make a lot of progress on 
our automated tests
[14:57] PeterThoeny: i like the idea of defining the criteria of t-x
[14:57] Lavr_: Many of the bugs were very basic and would have been difficult to find 
in auto test case.
[14:58] Lavr_: One additional thing we can and should do. Today we create the Patch 
branch on the day of the release.
[14:58] Lavr_: Maybe in future we create that 2 weeks or 4 weeks before and then ONLY 
bug fixes are allowed. Like with patch releases today
[14:58] PeterThoeny: well, my very personal opinion is that software can be kept very 
stable if every developer is manually testing every small change rigorously before 
checking in
[14:59] PeterThoeny: that is basically how twiki operated in the very early days when 
we had very few bugs poping up after a production release
[15:00] Lavr_: The last thing I have is - on the release day - next time - if I am 
releasing, I would like at least one developer to be on standby that day at any time.
[15:00] PeterThoeny: counter argument on early patch branch: branch at release so that 
developers stay focused on bug fixing
[15:00] PeterThoeny: until the day of release
[15:01] PeterThoeny: good point on standby, coordination question
[15:01] Lavr_: Yep. Should be possible.
[15:01] PeterThoeny: ok, +120 min
[15:01] PeterThoeny: shall we close?
[15:02] Lavr_: Let us do that. I will not write minutes until tomorrow. I have my own 
log to create it from
[15:02] PeterThoeny: ok
[15:02] PeterThoeny: nice chatting with all of you!
[15:03] Lavr_: For the log : Flenser, Lavr, Micha, Pth, Sven, CDot, Arthur, secret bot
[15:03] Lavr_: Good night.
[15:04] PeterThoeny: goo night, good morning, good afternoon tea time :-)