Session Start: Mon Sep 15 21:00:14 2008 Session Ident: #twiki_release [21:00] * Now talking in #twiki_release [21:00] * Topic is 'http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x08x18' [21:00] * Set by Lavr on Mon Aug 18 19:45:54 [21:00] Hello [21:00] Hi Kenneth [21:00] Hi Oliver [21:00] Hi there. :) [21:00] Hi Markus [21:00] Hi Markus [21:01] Hi Koen. [21:01] Peter, Sven and Bot. :9 [21:02] Is Peter here in person? [21:03] according to twikibot, his last message is 23hrs ago. [21:04] So the release meeting process is again down the drain. [21:04] hi all [21:04] i am half ear here [21:04] Hi Peter [21:04] correcting: 1min ago. ;) [21:05] have urgent stuff to attend, but will try to peak here once in a while [21:05] i did not call for a meeting yesterday because i am not clear what the process is now [21:06] with the new interim givernance team [21:06] s/giv/gov/ [21:07] I also wonder. None of my 4 interim governance partner has bothered to show up today [21:08] Which I just told all 4 of them in an email. [21:08] :-( [21:09] according to skype, Michael is not online. [21:09] for the rest, I dont have further contact addresses. [21:10] Well. As the only representative of the interim team I guess I have to represent all of us. If they disgree they could have fucking showed up [21:11] If you think I am slightly angry then you are wrong. I am VERY angry. [21:11] I can understand. [21:12] i understand yo very well [21:12] Let is give you guys an update on the interim governance status [21:12] We have had ONE meeting on Skype which was very productive. [21:13] We have since then had a number of email trails going on to address the urgent issues that we were asked by the community to address. [21:14] Peter, you will soon receive an email from Adam with a number of proposals about your status on the project. [21:14] I think you will find that there is something good to build on. [21:16] We are working on gathering some inspiration on how to build the association. Like a set of rules. And some proposal on membership inspired on how you get SVN checkin rights. [21:16] sounds good. [21:17] The overall question that seems to repeat itself both on Codev and among the interim board is - how do we ensure that people knows the difference between twiki.org and twiki.net [21:19] Ie. people agree that it must be clear what the difference is. But we disagree where there is an issue and where there is no issue. [21:20] Personally I am concerned that the more extreme oppinions are dominating over the more moderate opinions. [21:20] Simple because dominating people seems to be more loud and frequent in expressing opinions [21:20] What are the prominent places, where that matters? DownloadPage? What else? [21:22] On the DownloadPage all 5 interim members agree that two download boxes side by side will cause confusion for people in a way that looks like someone trying to "trick" people. [21:22] Noone wants to leave a negative impression. [21:22] ok [21:22] So we are discussing a clear presense, but in a way that combines..... [21:22] What are the other places, where there might evolve confusion? [21:23] 1. Making it clear what is the twiki.org download and what is a sponsered add for TWiki.net [21:23] 2. Making a fair presence for TWiki.net that makes the visitor aware of the fact that there is a commercial distribution with support. [21:24] We are still among the 5 of us discussing what is OK and what is not. [21:25] On the attribution connected to the TWiki name the hot issue seems to be the trailing TWiki.net part of the attribution. [21:25] Personally I do not understand the issue. [21:26] Are there other known OSS sites that face the same 'dilemma'? Did someone try to compile a short overview? [21:26] Peter, a general concern is if TWiki can be in the debian repository. [21:27] I think it is a common interest that TWiki can become standard packages in all the major distribution. Like OpenOffice is today. [21:28] That should have a high priority. Not for the sake of debian, but for the sake of a "true OSS" image. [21:28] So if the license to the TWiki brand name can be adjusted to be "debian free" then the most loud critique will be more silent. [21:29] It would be wise for TWiki.net and you Peter to address this directly with debian ASAP. [21:29] That would be good. [21:30] I also think that once it's "good enough for Debian", all other distributions should be able to carry a TWiki RPM once there's a maintainer. [21:30] There are too many amateur lawyers in the community that wants to interpret what debian free means. [21:31] it is better than debian tells us what they require of our Brand licence. Our GPL is fine. It is only the brand name license which is an open question. [21:31] I think its in .nets interests to solve that (asap). [21:33] I would think so too. And I think it is best of the issue (if there is one) is clears out directly between TWiki.net and debian. [21:33] that would be the best solution. [21:34] It is not debian that has raised the issue. It is members of OUR community that believe there is an issue. They may be right. Best would be if you Peter arrange a direct contact with debian to discuss the requirement of a brand license. I think this will result in the most neutral result. [21:35] * OliverKrueger pings peterthoeny [21:35] Any questions before we go to the next item? [21:35] nope. not at the moment. [21:36] not from my side. [21:36] Do you plan to publish ur internal discussion? [21:36] just a general question. [21:39] The next steps involve a direct negotiation between the interim board and Peter on the open issues. This requires that some details remain internal only until we have an agreement. [21:39] Ok. [21:40] I have no problem with internals. I was just asking. :) [21:40] But I will say that a as things look the board will offer Peter a fair deal and show Peter respect as the project founder. [21:40] But there are limits and we are also bound by the mandate given to us at the Summit which is already known. [21:41] My personal view is that the end result becomes a win-win. [21:41] on debian, i would need to look into details. the fact is that it was ok so far, so why make an issue now? [21:41] peterthoeny: Just to make sure, it stays "ok". [21:42] There may not be an issue. Someone in OUR community claims there is an issue. Best is for you to have the proposed brand/attribution license reviewed and approved. [21:42] .. reviewed and approved by debian. [21:44] My theory is that debian will be eaiser to deal with that some of the extreme opinions within TWiki community that may have other agendas. [21:44] s/eaiser/easier [21:44] :-) [21:45] We have people that think that "TWiki® is a registered trademark of TWiki founder Peter Thoeny" is OK and "TWiki® is a registered trademark of TWiki founder Peter Thoeny, TWIKI.NET" is not. [21:46] I am sure this is not what debian is looking at. [21:47] Lavr: thanks for the update. :-) [21:49] OK. I will as a benevolant facilitator for night (BFFN) continue to the next item. [21:49] :) [21:49] Review urgent bugs. [21:49] Given the audience I guess the only bug worth talking about is the TOC bug [21:49] I already flew over the Items and did not found any Item I can comment on. :-( [21:50] I am personally very thankful to you for addressing this old bug and I think the last update you did is a good solution. [21:50] np ;) It was bugging me, too... [21:50] Even the first one was quite alright even though there were examples where you could break it. [21:51] I understand the test case is also up to date now? [21:51] How much time did you spend on it? [21:51] uebera||: [21:51] The existing ones, yes. They now stay in sync. [21:51] Too much ;) -- the better of two workdays I should have done something else. [21:51] I played a little with it yesterday and to me the fix looks quite OK now. [21:52] We have a I18N issue still open related to TOC but your fix does not prevent a later fix for that. [21:53] Is it one of the current blocker list? [21:53] The issue is that our current trunkation of the anchor to 32 chars can break a UTF8 16 bit char in two. [21:53] Only when TWiki is setup for UTF8 [21:54] Let me find the bug item. [21:54] Ah this one, yes. Actually, the disambiguation logic which truncates the anchor to make "room" for the counter should be tested in this respect as well. [21:54] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4074 This one? [21:56] That looks like a duplicate of the one I was thinking of. [21:56] There's a patch attached ;) -- I think I have to duplicate one line for the anchor renaming. [21:57] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5926 [21:58] For some reason it does not list itself in the release blockers SEARCH. I wonder why [21:58] Ah. It does. I had clicked on WebChanges [21:59] On Item5926 the reporter has suggested to URL encode the headline for the anchor. [21:59] But I think this fix is wrong. [21:59] At last release meeting I wanted to email Richard D. But I never got to it. [22:00] I guess if we urlencode a string, modify it, and urldecode it afterwards, it should always work regardless of the setup. However, this is a big expensive, I fear. [22:01] Does MediaWiki handle this? [22:01] dunno [22:01] (hm, that's PHP, we'd need a perl project to compare) [22:02] I have tried to do a convertion to unicode before and after the trunkation. It works. But... [22:03] I fear this will be a very bad fix later when we fix the generic UTF8 problem. [22:03] We seem to patch utf8 problems here and there all the time. There must be a more basic problem we should address. [22:04] But none of our current developers seem to have the knowledge about utf8 that is needed to make a long lasting solution. [22:04] It would be a workaround _for now_, however. If that can be tested/implemented and gets reported often, we should address it, I guess. [22:04] Yes, it takes some time to analyse that, unfortunately. [22:05] The problem with the URL encode is that you then URL encode the first 8 bits of a UTF8 char. Will that always work? [22:06] I was quite sure about that. I'll have to retry this again, though. [22:06] I can tell you later exacty where in the code I know the problem is. [22:07] Another other bugs we want to cover tonight? [22:07] I will continue on Item5442 finally. [22:08] updating extender scripts in extension packages. [22:08] (update: "Unicode Character '' cannot be encoded using standard URL encoding. So it won't work.) [22:08] Markus. OK. that clears that. [22:09] Oliver 5442 - excellent. [22:10] I'm working on Item5987 as well, but it's not an urgent one. [22:10] Yes. I followed 5987 [22:10] I am not sure what is the best with this one. [22:11] I think if it's possible to identify settings which use their default value, they could be left out and all will be happy. [22:11] I can think of two cases where the URL params are important [22:12] 1. EditTable [22:12] Maybe I'll cross Sven's path regaeding Item5804, but I still have to follow the path how parameters are handled. [22:12] * Rafael_Alvarez has joined #twiki_release [22:12] * Rafael_Alvarez is now known as Soronthar [22:12] * Soronthar has quit IRC (Client Quit) [22:12] 2. topics using URLPARAM [22:12] In both cases keeping the url params is an advantage [22:13] * OliverKrueger has to leave quite soon. [22:13] if these reflect settings that were changed from a default, they should be kept, yes. [22:14] So it is a tradeoff between causing a page reload when clicking the TOC and maintaining the URL parameters right? [22:14] yes [22:15] I am unsure what I prefer. [22:15] This is where it would have been nice if we were 10-15 people tonight [22:15] Yes. Hopefully, someonce comments on this. [22:16] I probably would prefer the latter. [22:16] I will highlight this one bug in the minutes [22:16] I also think preserving the URL params is more important [22:17] I only found out after loading a _big_ page with a lot of includes... the reload took 5-10 seconds. On small pages, you don't recognize this (though it's another server request, so if there's a higher load, you would be glad to save those) [22:17] If people made a twiki app with this they will really want it to be maintained also after clicking the TOC [22:17] That's what I have to look up... in that case, maybe the parameter are even attached on first load? Then it's not a problem (no relad will happen). [22:18] I got to go. BIG THANK YOU to Kenneth, for the work in the interim board, and another one to Markus for the TOC fix. :) [22:18] cu [22:18] cu, Oliver. [22:18] * OliverKrueger is now known as OliverKrueger|aw [22:18] (and a big thank you to you, too, Kenneth ;)) [22:20] OK. Bye Oliver [22:20] Thanks for joining [22:21] The last item on the agenda is feature proposals. None are up for decision. [22:21] So that is it. End of the meeting unless someone have additional [22:21] OK. Thanks for those few of you that showed up. [22:22] Ah, there's a question regarding the security release from my side. It's not on the agenda, though. [22:22] Go ahead [22:22] I was a bit surprised to hear that it was decided to roll out all new code in the 4.2.x branch with the configure patch. [22:23] "new code"?? [22:23] I looked up the commits, and indeed, all other changes aside from the TOC modifications seems quite "small" and isolated. [22:24] Ah. With roll out you mean - did not include? [22:25] Sven did the 4.2.3 release without waiting the few hours it took for the rest of us to react. I tried to stop it so we would have a 4.2.3 with the known issues included but it was too late. [22:25] I am not happy with the 4.2.3 that was released. We should have followed the security process and released a hot fix first and 4.2.3 later. [22:26] ...back [22:27] on security advisory, it was totally uncoordinated [22:27] We will soon release a 4.2.4 that will contain the known issues. [22:28] Yes. Sven paniced. [22:29] also, the download page has an excessive notice of the issue [22:29] Yes. It scares away anyone. FUD. [22:30] issue is overblown imho since our docs clearly state to lock down the configure script [22:30] the security team did not triage the issue [22:30] i would have triaged it as a severity 3 [22:31] e.g. handle as bug [22:31] and in addition issue a security audit, not a cve [22:31] as we have done in the past [22:31] The bug itself is bad but it has to be combined with the fact that only sites where the installer directly ignored the installation guide, and the example config and the Codev.ApacheConfigGenerator there was no need for a panic. [22:31] security audit just goes to all on twiki-announce [22:32] question is what we should do now [22:32] Yes. We should have announced it on the twiki-announce even though it was may have been a 3. [22:32] retract the cve? proceed with security advisory? [22:33] ARGH. [22:33] Sorry, dialup connection problems... [22:33] I am not sure where we are with that now. [22:33] * AndreU has joined #twiki_release [22:34] with "roll out", I meant include/distribute/package them. [22:35] Markus. But as I understand the 4.2.3 does NOT include any other fixes than the configure update. [22:35] Maybe I just understood your statement wrong ;-) [22:38] * AndreU has quit IRC (Client Quit) [22:38] Yes, it does not. But as I understood both CDot and Sven, it was planned to build a release based on the current revision of the 4.2.x branch! [22:38] They said it has been decided (which implies the security team must have discussed this, and you're both on it, right?) [22:38] It was planned by me to build a 4.2.3 in mid September. [22:39] Yes, that's what was stated on the last release meetings. [22:39] * AndreU has joined #twiki_release [22:39] However, the TOC code could have been part of the emergency update, and that would have been extremely bad. [22:40] * AndreU has quit IRC (Client Quit) [22:40] No. [22:40] I'm feeling lucky that the testcases didn't went through, because I loved to have a look at it before. [22:40] The emergency update would not have been released if it had been decided according to our process. [22:40] Ah. [22:40] We would have provided an updated configure and a secure advisory warning on the twiki-announce list [22:41] And then within a short time a 4.2.3 with the known good fixes included. [22:42] That's what I expected. [22:42] Now it will become a 4.2.4 and it will be released soon but not in a panic. [22:44] i have to leave now [22:44] thanks all for attending; please continue [22:44] Me too. Again sad that so few of the developers bother to show up. [22:44] I makes me doubt if the new Governance is worth spit. [22:45] But I am very happy to see those of you that did show up. Especially you Peter ;-) [22:46] We end the meeting here. [22:47] cu, Peter. :) [22:47] I will post the minutes. And I expect ONE person to give me hell on the minute topic but I do not care anymore. Tomorrow I will give a presentation at a Wikiseminar. [22:47] Ok. Thanks. [22:47] http://www.videndanmark.dk/16-9-08-Wikiseminar.311.0.html [22:48] I will speak kindly about TWiki naturally [22:48] I heard what I wanted to hear. :) Looks interesting... ;) [22:48] I have edited the download page and removed the yellow box which was more a "go away" box than a help. [22:49] If you want to reach the people that already downloaded TWiki it is not on the download page. [22:49] Yes, right. [22:50] I also have a blog to write. But not tonight because the lack of participation would create a negative vibe blog post. Some other day. [22:50] Have fun tomorrow! :) [22:51] * PeterThoeny_ has joined #twiki_release