Session Start: Mon May 07 22:02:06 2007 Session Ident: #twiki_release [22:02] * Now talking in #twiki_release [22:02] * Topic is 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x05x07' [22:02] * Set by wnorris on Mon May 07 17:39:48 [22:02] thanks [22:02] hi kenneth! [22:02] Hello all [22:02] hello [22:02] hi kenneth [22:02] i saw the twiki heart award from kenneth [22:02] i second kenneth! [22:03] kenneth, are you back from the mini vacation? [22:03] Yes we had a great time in Portugal [22:03] ah, just read it. thanks [22:04] :-) [22:04] * gordont has joined #twiki_release [22:05] I will get on the minutes unless anyone protest [22:05] thanks [22:06] we have new folks at the meeting [22:06] bigtuna and gordont, could you please introduce yourself? [22:06] and thanks for stopping by :-) [22:07] I'm Gordon Tetlow [22:07] Welcome bigtuna and gordont. If you give your Wikinames from twiki.org I will add you to the minutes. [22:07] I work on Sony Online Entertainment [22:07] GordonTetlow (creatively enough) [22:08] gordont: is that http://www.station.sony.com/ ? [22:08] yup [22:08] how big is twiki at sony online entertainment? [22:09] Pretty big actually. Pretty much all of our game teams use it to share data. [22:09] Management uses it to check on game teams, etc [22:09] nice! [22:09] i did once a consulting gig for a gaming company [22:10] (now acquired by M$) [22:10] for those new, please review http://twiki.org/cgi-bin/view/Codev/TWikiRelease04x01Process [22:10] it gives an overview on the purpose of this meeting [22:10] that will be a big read :-) [22:10] gordont: how about you? [22:11] sorry, i meant bigtuna [22:11] sven_ remains dormant... [22:11] btw, i have a hard stop at +90 min (next meeting) [22:12] +11 min now, shall we start? [22:12] who is facilitating? [22:12] (i can do again if you wish) [22:12] How about you ;-) [22:13] ok, me [22:13] so let's start [22:13] proposed agenda: [22:13] # 1. Action Item Review [22:13] # 2. Review Proposed Features [22:13] # 3. Release Schedule of TWiki Release 4.2 [22:13] Go ahead peter. I have resaved todays agenda so refresh [22:13] anything to add/change? [22:13] http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x05x07 [22:14] a number of features from TWikiFeature04x02 can be discussed [22:14] ok, that is #2. [22:14] ok [22:14] The new app has a status so that the topics ready are listed. We have 5 today. [22:14] nice page btw [22:15] ---+ action item review [22:15] # Kenneth to follow up with Crawford on the SimpleFieldQueriesInMETASEARCH [22:15] # Peter to quickly follow up with spec proposal on SimpleFieldQueriesInMETASEARCH [22:15] i gave my feedback [22:15] kenneth as well [22:16] we have not heard from crawford [22:16] That was if Crawford was the committed driver. But when you looked at the history then it was actually Crawfords own proposal so it was obvious that he was the committed driver. So that is done. I did not put it as ready for decision yet [22:17] since this is a clean enhancement to METASEARCH and SEARCH i think it will get accepted easily [22:17] yes, the discussion needs to go on [22:17] so lets cover this at a meeting when ready [22:17] Yes. The only decision to finish on that topic is if we only extend METASEARCH - at least in the first round. [22:18] my personal inclination is to extend SEARCH first, since this is the more useful query [22:18] # Peter: Create a TWikiBetaTesting topic in Codev, with info for beta testers [22:18] this is still pending :-( [22:18] i will do in time for 4.2 release [22:19] ---+ 2. Review Proposed Features [22:19] # AddGlobalSettingToAllowNonWikiWords Add global setting to allow non-WikiWords [22:19] http://twiki.org/cgi-bin/view/Codev/AddGlobalSettingToAllowNonWikiWords [22:20] It is a two day old proposal. [22:20] i think this setting makes sense [22:20] i am already using some webs with the noautolink set [22:21] there are some bugs that need to be fixed [22:21] i opened a bugs topic on this [22:21] in any case i support arthurs suggestion [22:21] oh, 2 days old [22:21] I also think the proposal is fine. My only concern is if people have had enough time to read it and comment. [22:21] why is it "ready for release meeting"? [22:22] ok, we can leave it open for the next 12 days [22:22] anyway, i think this is a no-brainer and does not need a release meeting decision [22:22] * OliverKrueger has joined #twiki_release [22:23] hi oli, welcome! [22:23] We do not have to always wait 14 days. But 2 days is a bit little. I would implement it and take the small risk that someone raises concern. [22:23] (my client is pretty slow) [22:23] Good evening, everyone. [22:23] :-) [22:23] I will leave it for a number of days [22:23] arthur: sounds like a government agency? [22:23] have to finish other things first [22:23] yes, sounds fine [22:24] http://twiki.org/cgi-bin/view/Codev/AddTWikiAdminUser [22:24] I was pushing because we are working towards a release [22:24] or were? [22:24] use the configure password for a new TWikiAdmin account [22:25] ..one sec... [22:25] Yes. A very long discussion has been going on. I have been very concerned but with Crawfords latest proposal there may be a technical viable solution. [22:27] I must say that it would be nicer if discussions like these did not end up with very personal attacks. [22:27] I am sure it was not meant personal [22:28] but it did not sound constructive either [22:28] evenin [22:28] too big a topic to grasp for now [22:28] i am just reading the last comment by kenneth on the topic [22:28] Hi Sven [22:28] hi sven [22:28] no, it was not meant the way Lavr read it [22:28] yes, this simple approach sounds good [22:29] but then i'm sure he didn't mean to make his sound that way either [22:29] hi sven [22:29] what I'm still trying to make clear [22:29] is that what you're tlaking about, is the tiniest part of the tip of the iceberg [22:29] a distraction (for me) [22:29] from the real hard work i have to do to get the code to that point [22:30] and all along, i've had Lavr say things like [22:30] you may as well not do it, if its going to work that way [22:30] for this release meeting we are primarily concerned about the spec, not the implementation [22:30] yes [22:30] and the final user seen interface is still dependant [22:30] on the implementaion that is actually possible [22:30] basically [22:31] at this point, trying to nail down what you want [22:31] may never happen [22:31] just because it turns out to be hard to do [22:31] I don't think this is the case [22:31] i think what everybody would like to see is a clearly documented spec on that topic [22:31] yep, so would i [22:31] but that requires twiki to be re-coded [22:31] Sven. If it is not possible to implement now then simply, do not remove the little # from Set ALLOWTOPICCHANGE in TWikiAdminGroup [22:31] in a probably incompatible way [22:32] Lavr, that leaves our most at risk customers [22:32] continueing to be open to attack [22:32] and thus makes twiki continue to be the laughing stock of the security aware admins [22:32] this is somehow, sub- optimal [22:32] what is so difficult on the simple approach kenneth stated? (last comment) [22:33] dunno atm [22:33] i'm not at the point where i know [22:33] PeterThoeny: the problem is how to decide how to auth a user [22:33] thats what i'm trying to tell you [22:33] 90% of the issue [22:33] if there is more than one auth provider, how do you decide which provider to pass it off to? [22:33] It is not such a big security issue. Most other CMSs and Wikis has a default admin user and password instead. Under all circumstances do you have to start from insecure and then close the door. [22:33] is that we can code it to do anything, at the risk of making it incompatible with existing installs [22:33] no [22:33] most CMSs don't have defailt login & passowrd at all [22:34] gordont nails down exactly my original concern. [22:34] if tahts all you are worried about [22:34] then you can simply wait til i have the code done? [22:34] If you use Apache auth then you cannot also authenticate using the configure password with the same auth method. [22:34] of course, the question of security out of the box is actually a separate issue entirely [22:34] cos the answer is, the code i'm writing will try to work it out [22:34] If you use Apache auth then you cannot also authenticate using the configure password with the same auth method. [22:35] mmm, did you read what i wrote? [22:35] i know i write poorly [22:35] Sven. Yes but you can authenticate via a form field like when you save data in configure. [22:35] not only do we get to 'mix' multiple usermappers, but we're talking about 'mixing' multiple Login types too. I could conceivably (somehow) configure TWiki to use mod_ldap_auth for most users, and configure it to use TemplateLogin? for becoming admin, or for external temporary users / contractors... [22:36] or [22:36] Thinking further on adding an AdminLogin? page, this is pretty much the same as telling TWiki to use TemplateLogin? for some users (ie TWikiAdmin? ), either as a user, or as a sudo. [22:36] which, I must add [22:36] No Sven. You are overinterpreting the intension. [22:36] is similar to what i was hoping to make the code do [22:36] no [22:36] i'm adding needed functionality [22:36] and reducing the need for a special case [22:37] ALL we really NEED is a method to get a user add as an admin. That is the original requirement. [22:37] no [22:37] all we (as in the client's i'm reresenting) [22:37] is a fully pluggable auth system [22:37] that allows them to provide auth that works in their situation [22:37] sven_: is that a reality for Freetown? [22:38] it was already working in 4.0.2 [22:38] just unreleased, due to seperate issues [22:38] and what you're talking about, is a single configuration example of that [22:39] i think the real objective for freetown is to make the admin group secure; the simple approach with special predefined twikisuperadmin login solves this [22:39] anything else is a "nice to have" [22:39] Let us not extend the scope of the proposal we are discussing which is "use the configure password for a new TWikiAdmin account" [22:39] um [22:39] there is alot of work going on to make this happen [22:40] tbh, most of it is testing work [22:40] because twiki's auth is very lacking in tests [22:40] sven, could your try to bucketize the work, one bucket for freetown, one for georgetown? [22:40] lemme put it this way [22:40] I _WILL_ be releaseing a twiki release that has all this work in it before July [22:41] if you want to make freetown something smaller [22:41] then that takes a load off my back [22:41] and puts it on cdot [22:41] and then i'll make my own release to satisfy the needs i have [22:41] sven_: is the auth work in progress available for review? [22:42] the currently public progress is in svn MAN [22:42] I'd be interested in looking at it for my own purposes because of our unique needs at my company [22:42] MAIN [22:42] all else, is, yep, not public [22:42] what is needed for the tests? [22:42] lots of unit tests [22:42] detailed ones for all edge cases [22:43] and then integration testing [22:43] BEFORE we can decide if we want this feature or not we need to know what we get. Ie. a define spec of how it will work. Right now I feel kept in the dark. [22:43] lavr, how it will work is implementation [22:43] NO! [22:43] and most of that is refactoring of the structure [22:43] how it will work [22:43] is not how it appears to the user [22:44] How will a Freetown ApacheLogin mod_xxx_auth authenticated installation register the first admin user? [22:44] sven, i am with kenneth on this one; we do not expect a very detailed spec, but a good overview spec will help in getting the buy-in [22:44] THAT is not implementation. THAT is spec. [22:45] i'm still parsing Lavr's q [22:45] And as it seems to me if I do not use TemplateLogin I have to hack the TWikiAdminGroup topic as a text file to get the first admin access. [22:45] huh? [22:45] we are a community driven project, where transparency is important [22:45] Thinking further on adding an AdminLogin? page, this is pretty much the same as telling TWiki to use TemplateLogin? for some users (ie TWikiAdmin? ), either as a user, or as a sudo. [22:46] the UI details are still in flux, but my current opinion, as doccoed on the topic [22:46] is that we are quite able to provide mutliple simultanious loginmanagers [22:46] time check: +45 min [22:46] depending on context [22:47] so if you use mod_xxx auth for the primary users [22:47] that will not prevent use from also using templatelogin (or a simplified version for AdminLogin) to auth the magic twiki user [22:48] or to set the sudo group [22:48] point is, with the code that I've already commited [22:48] Why suddenly extend it to login managers, sudo groups, and templatelogin? [22:48] because thats part of the implmentation i need to do [22:48] and that happil solves your need [22:49] The simple need is to be able to edit the TWikiAdminGroup topic to setup yourself as admin. [22:49] we already covered that [22:49] your simple need is not my need [22:49] but i can give you your need, and many other peoples needs [22:49] at the same time [22:50] How? I want to know if admins now have to setup two different authentication schemes. [22:50] my endpoint, will be to have it trivial for a user [22:50] this looks like a complete redesign/rewrite of the login and auth model [22:50] to configure to use openid (obviously) [22:50] PeterThoeny, not really [22:50] its been a surprisingly simple refactor thus far [22:50] How? I want to know if admins now have to setup two different authentication schemes [22:50] one mo [22:51] form topic [22:51] working out a way in configure to let the user clearly select & mix from which mappers to get stuff [22:51] * ie, to get users from ldapmapper only [22:51] * but to get groups from ldap and twiki topics [22:51] * and howto mix same groups together, or to over-ride [22:51] right now, my test imple [22:51] is 2 dropdowns :) [22:51] but thats just a bit dumb [22:52] ldapmapper? [22:52] what about it? [22:53] we should move on in the interest of time [22:53] sven, until next time, could you please try to write a clear spec at the top of that topic? [22:53] i have tried [22:53] that way we will have an easier time at the release meeting [22:53] i keep hoping someone who thinks they can write [22:53] will have a go [22:54] rather than me feeling like lavr is just attacking me [22:54] because his needs are much smaller than mine [22:54] i see it differently, i feel that we spend a lot of time discussing the spec [22:54] you see, the personal attack thing is going both ways [22:54] me engineer [22:54] kenneth is asking questions i am also intersted in hearing [22:54] spec means timing diagrams [22:54] It is not MY needs. I am trying ensure that TWiki does not become a nightmare to install. more than it already is [22:55] yes, and your eg's don't make sense to me [22:55] as they are non-simple situations [22:55] Sven. I am interesting in how the user/admin see the function. It is not the code implementation behind that concerns me. [22:55] sven: i think all we would like to see is a functional spec [22:55] y, i think i suggested before, [22:55] no details needed (timing diagrams etc) [22:55] we cna make a functional spec of what we dream it would be [22:56] but there's no garrantee that it will be true [22:56] We need a spec of what you intend to implement for Freetown so we can decide if we want it or not. [22:56] backwards compatibility being the limiting factor [22:56] the top of the topic details what i am implementing [22:57] 99% of that being refactorings [22:57] sven, ok to make this as an action item for you, to write a functional spec? [22:57] we can but try [22:57] ok [22:57] next: [22:57] but i [22:58] will be working on the refactorings more [22:59] Thanks. [22:59] sven, it helps to get your implementation accepted more easily if we have a spec that can be discussed effectively in the next release meeting [22:59] as not adding the feature [22:59] but releaseing the refactorings [23:00] time check: +60 min [23:00] makes freetown worth it for non-simple users [23:00] # http://twiki.org/cgi-bin/view/Codev/CreateHomeWebVariable - Create HOMEWEB variable as distinct from MAINWEB [23:01] There are two proposals in the proposal. First one Lynnwood would commit to implement and the 2nd he needs a programmer to help him with. [23:01] on this one it looks like we have an agreement to add 4 settings [23:01] question if these are configure or twikiprefs settings [23:02] yeah, it would be nice to have a policy on that q [23:02] variables: WIKIHOMEWEB, WIKIHOMETOPIC, WIKIHOMELABEL and WIKIHOMEALT [23:02] Actually the configure thing came up when I asked if it has performance impact to add yet more variable used all the time to TWikiPreferences. [23:02] like, in the interests of upgrading [23:02] (or configure settings) [23:02] we remove twikiprefs to configure [23:03] (that would be my personal pref..) [23:03] all prefs? [23:03] for upgrading, being able to have the distributed topics read only [23:03] would rock [23:03] I am also concerned about throwing more variables on TWikiPreferences. It is complex enough already. [23:03] sounds interesting. [23:03] ie, removing twikiprefs long term [23:04] sven_: well, there is the distinction of Main.TWikiPreferences vs TWiki.TWikiPreferences [23:04] then we could do away with Main.TWikiPreferences as well [23:04] gordont, ya, but that does not stop users [23:04] Or at least limit them to settings that you may want people to be able to overwrite later. It is then more logical to have them defined in preference topics. [23:04] i think the real question is this: does a variable need to be redefined at a higher level? [23:04] better to create systems that avoid the issues [23:04] if yes, make it a pref setting [23:04] if no, make it a configure setting [23:05] or [23:05] it would be a site wide variable [23:05] These you would set site level once and for all I would assume. [23:05] PeterThoeny: also, the question of losing the ability to allow certain users to edit the preferences without giving them access to configure [23:05] do we think long term, that configure will become the admin UI [23:05] gordont, na [23:05] you could still over-ride them in webprefs [23:05] gordont: good pint, yes [23:05] pint of beer :-) [23:05] s/pint/point/ [23:05] mmm, beer [23:06] moving to configure [23:06] does not mean you can't over-ride them [23:06] just that we're moving where the site wide config is [23:06] all to one place [23:06] is the notion that wikihomeweb would be the "frontpage" so to say? [23:06] or that it would be where user topics would go? [23:06] frontpage only [23:06] cause I think of "home" like I do on a unix system, a place for users [23:06] sven, that would be a spec change: expose configire settings as prefs settings [23:06] ie, where twiki/bin/view goes [23:06] has security implications [23:07] It is the default place you end when you do not give any path to the TWiki URL [23:07] ya, no different from twikiprefs already y [23:07] ok, lets focus on the actual topic [23:07] the name is a bit confusing for a unix admin like me. I think of home as a place for users =) [23:07] but it's only a passing concern =) [23:07] and, if anyone inclined, create a codev topic on configure/prefs spec change [23:08] shall we vote on configure or prefs settings for the 4 settings? [23:08] 1: configure setting [23:08] 2: twikiprefs setting [23:08] Names was already debated on the topic. It is difficult to come up with a name that cannot be misinterpreted. [23:09] ONE QUESTION. [23:09] If we implement it as configure setting then I assume this also means that we have to add a little code that defined the 4 as TWikiVariables [23:09] To be able to use them later. [23:09] yes [23:10] AND we need a driver to implement it then. [23:10] how often would we reasonably think these would need to be referenced? every page draw? [23:10] on every page at least twice, since it is in the breadcrumb and banner logo [23:10] Yes. It would be used in breadcrumb and logo [23:10] we cache variables though, right? [23:11] so it would only be a single hit to the preferences page, right? [23:11] then the big question is, do we already expect that every page draw already hits the preferences page? [23:11] in that case, it's moot [23:12] It all adds up. If we long term want to remove more and more from TWikiPreferences then it is a bad thing to start adding more [23:12] Lavr: but now the user has to configure things in 2 places? [23:12] I suppose they already do [23:12] true, however, if we add it to configure we still need to expand 4 variables [23:12] mmm, MAINWEB is configured in configure? [23:13] and this setting is 'similar'? [23:13] gordont: twiki prefs are expanded on every page view anyway [23:13] but if the variables in the pref page is already cached from a previous reference, is it really much of a load? [23:13] Yes. E.g. we recently moved the WEBMASTER email to configure. And we have many settings in configure already. I think static site level prefs you do not overwrite later belongs better in configure [23:13] it's already in a hash in memory [23:13] its not a load issue at all [23:13] as both data sources are loaded [23:14] it really _is_ a question of which direction we want to go for the long term [23:14] according to the topic "What is the performance impact on this?" [23:14] otherwise, flip a coin, it matters little [23:14] I agree with Sven. [23:14] so I was responding to that =) [23:14] personally i think for consistent browser experience it is not good to redefine the logo link [23:14] answer is, none [23:14] so adding it to configure is ok [23:14] (or should have been) [23:15] WHO takes the implementation if we add to configure? [23:15] there have been users that want a logo per web [23:15] there will be a very small performance impact either way, less if done in configure [23:15] actually, a customized breadcrumb per web would be kinda neat [23:16] Lavr: didn't you already sign up to do the implementation for configure? [23:17] so far we have many settings in twikiprefs that are logo ui related [23:17] Darn I did tell Lynnwood that I knew how to do that. [23:17] Caught with my pants down [23:17] WEBLOGOIMG WEBLOGOIMG WEBLOGOALT FAVICON WEBBGCOLOR etc [23:18] actually, make that site wide: WIKITOOLNAME WIKILOGOIMG WIKILOGOURL WIKILOGOALT WIKIHOMEURL [23:18] so for consistency it would be better in twikiprefs [23:19] for performance it might be better in configure [23:19] prefs has the bonus of being very little work [23:19] (i suspect an impact that is not measuarable) [23:20] hmm, do we need to do anything at all? [23:20] WIKIHOMEURL aleady allows one to define a custom home url [23:21] specifically, WIKIHOMEWEB, and WIKIHOMETOPIC are covered by this setting [23:21] WIKIHOMELABEL and WIKIHOMEALT would need to be added because of breadcrumb [23:21] I guess it was mainly for where you end when you hit TWiki in the breadcrumb. I think that is hardcoded to MAINWEB now. [23:21] time check: +80 min [23:22] (i need to sign off in 10 min) [23:22] But for the logo stuff we may not need anything new. It was you Peter that added the 3 extra. [23:23] looking at the existing settings i suggest to stay consistent and put the new ones into twikiprefs [23:23] Lynnwood just wanted HOMEWEB [23:23] * sven_ is now known as SvenDowideit [23:23] yes, the first entry in view is [[%MAINWEB%.%HOMETOPIC%][%WIKITOOLNAME%]] [23:23] yes, he wanted that for breadcrumb [23:23] that is easy to change [23:24]