Session Start: Mon Jun 26 23:01:26 2006 Session Ident: #twiki_edinburgh [23:01] * Now talking in #twiki_edinburgh [23:01] * Topic is 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x06x26' [23:01] * Set by SvenDowideit on Mon Jun 26 11:43:29 [23:01] Good evening/afternoon [23:01] hello Lavr [23:02] excellent preparation in release meeting topic, thanks a lot [23:02] hi kenneth [23:02] Indeed! [23:02] Thanks [23:03] here too [23:03] * CDot has joined #twiki_edinburgh [23:03] hi crawford [23:04] 'evening c [23:04] steffen, i have seen that you pretty much cleaned up the support web while i was gone [23:04] hi Peter [23:04] good holiday? [23:04] bravo, excellente [23:05] yeah, wanted to see if it was possible [23:05] yes, very nice holiday [23:05] I think I'm closing in on 10 open items or so, so it was :-) [23:05] the yellowstone park is a place i recommend anyone to visit at least once in a lifetime [23:06] Hi Stef [23:06] all the colors, shapes and smells [23:06] PeterThoeny: did you climb El Cap? [23:06] or just stick to Half Dome? [23:06] i am not a climber [23:06] oh, you are talking about yosemitee (sp?) [23:07] do you remember that canadian chap from WikiSym [23:07] very tall chap (I forget his name) [23:07] the former is in idaho, where all the geysirs are [23:07] the latter is in california [23:07] oh, ok. Both start with a "y" ;-) [23:08] i mixed them up too [23:08] *g* cleaning out the hash too early? [23:08] don't rember the canadian person [23:08] SteffenPoulsen: the hash? hash pipe, or hash browns? [23:08] * MartinCleaver has joined #twiki_edinburgh [23:08] hi martin [23:08] hi Peter [23:09] we have criticall mass to start [23:09] lynnwood is missing though [23:09] he is a good facilitator [23:09] is Kenneth here? [23:09] I was thinking only one entry left in "y"-hash-style .. not that the brownies doesn't sound interesting :-) [23:09] Yes [23:09] Preparing minutes. [23:10] yes, let's get started. Thanks, Lavr [23:10] Facilitator? [23:11] i can do it if you wish [23:11] that's settled then :-) [23:12] ok, kenneth for mm, me for talking [23:12] aka facilitating [23:12] Before we start - the agenda is a bit confusing. So you need to clarify Peter. The one liners do not match the sections further down [23:12] anything to add to the agenda? [23:12] http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x06x26 [23:13] * Revisit rule of changing API in non-backwards-compatible way - was agreed last meeting. Is this a carry over error? [23:14] I'd guess so. [23:14] oh, yes, that is a doc bug [23:14] just look at the toc [23:14] anything to add to the agenda? [23:15] nope, nothing for the agenda from me [23:15] ok, lets start [23:15] Who added Removal of !WebPreferences (an admin-oriented item) from normal users' left bars [23:15] That is a new one [23:15] martin i think [23:16] ---+ 1. Review Previous Action Items [23:16] TWiki Doc Users Focus group [23:16] It is number 5 then. I have saved the topic so it is updated [23:16] y, I did [23:16] * Soronthar has joined #twiki_edinburgh [23:17] * Twilight\ has joined #twiki_edinburgh [23:17] Welcome Twilight. That is a nick I do not know. A name for the minutes? [23:17] arthur, do you want to summarize our first meeting? [23:18] doc meeting [23:18] The doc group has met, and we have set a number of action items - [23:18] Twilight\ is n=ask@17.84-48-138.nextgentel.com * Anders Steinlein [23:18] Twilight\ on #twiki_edinburgh #twiki #tomcat #svn #django #postgresql [23:18] Twilight\ using irc.freenode.net http://freenode.net/ [23:18] Twilight\ is identified to services [23:18] Twilight\ End of /WHOIS list. - [23:18] We will create drafts of twiki.org home, Plugins home and Support home [23:19] we'll leave Codev as is for a while [23:19] Lavr: i'm just a curious twiki user hanging out in #twiki, coming here just to lurk ;) [23:19] Lavr: Anders is my name [23:19] You are very welcome [23:19] :) [23:19] Twilight\: You are very welcome, if you have a registered username at twiki.org, we will put a link to it in the minutes under "lurkers" :-) [23:20] I have a proposal for 4.1 that may/will impact the doc work in Plugins web [23:20] the main idea is to create 'easy' entrances for new visitors, evaluators and such [23:20] do you want to discuss that now, or later? [23:20] to to write new 'overview' topics [23:20] the doc team is probably meeting again this week, date not set yet [23:20] crawford, let's discuss that at the 4.1 focus [23:21] and to remove existing links that go directly into Codev and Plugins [23:21] so we've set our focus, but need to do our homework :-) [23:21] * ArthurClemens presses ourselves [23:22] (writing is hard, actually) [23:22] i think we had a good initial meeting [23:22] We have more time for doc work now that 4.0.3 is out of the door. [23:22] but a lot fo work ahead [23:22] "lot of" [23:23] If we follow my proposal timing wise later I plan to not test for a month and mainly focus on doc work [23:23] we've also suggested to use Google to index Support web [23:24] good idea [23:24] which is a new idea for TWiki [23:24] anything to add to the doc focus group part? [23:24] still we need better support for topic summaries [23:25] and topic titles [23:25] for your interest: http://developer.jot.com/WikiHome/2006-5-31-SeoPlugin [23:25] have you captured your goals somewhere? [23:25] (read another time) [23:25] Yes. I found that the Category searches in our distro docs return summaries that are best case useless and worst case confusing. So there is a low hanging fruit to persue there [23:25] yes [23:25] so we all know what you are working towards? [23:25] the doc group has a playground web [23:26] to write drafts [23:27] And avoid confusing users with unfinished proposals that we may throw away [23:27] should we make it public? [23:27] at some point, yes [23:28] we should consider it next meeting I guess, see where our homework has brought us [23:28] perhaps public but obfuscated: If you know where to look, you deserve to check what's in it [23:28] but i think it is better to let the doc team work out a 25% draft or so [23:28] I think having the doc team work in private is a recipe for disaster, FWIW [23:29] you will roll out something that everyone hates. [23:29] release arly, release often [23:29] early [23:29] so by all means have it read-only [23:29] but please share what you are doing. [23:29] yeah release early is the right thing, only history shows that this is a sensible topic so we need to reach a somewhat internal agreement first [23:29] thanks for the feedback, the doc team will discuss when to open it up [23:30] when we have highlevel goals / vision in place we will release I think [23:31] I don't have a problem in opening up now [23:31] If we have a meeting again end of this week we can open up right after. [23:31] that sounds good, let's put it on the agenda for next meeting [23:32] yes, the doc team will discuss this [23:32] next? [23:32] basically i am open for opening it up early if we get constructive feedback [23:33] ok, lets move on [23:33] ---++ TWiki 4.0.3 release [23:33] Sven did a great job on that [23:33] i have seen that all went well [23:33] with a follow up [23:33] yes, great job sven [23:34] For next release we need to automate making the -changes file. [23:34] And we need to make it as part of release candidates so we can test that also [23:34] even then we had some last minute changes that deserved more scrutiny [23:34] there are a few items left [23:34] as indicated in the Codev.ProductionReleaseChecklist [23:35] a.i. for peter: followup on 4.0.3 release [23:35] such as index.html update [23:36] anything to add to the 4.0.3? [23:36] add to the zip? [23:36] nope not from here - thanks to everyone involved in doing the 4.0.3 release also from me [23:36] no, the action item review [23:37] righty [23:37] yes, a big thank you to all involved :-) [23:37] it is nice to see that we have documented the process "good enough" [23:37] documentation of issues will be next (last?) in the meeting [23:38] yes, that is later, "visibility" [23:38] ---+ 2. Next Release 4.0.4 or 4.1 [23:38] at +38 min [23:38] depends what's in it [23:39] actually, we didn't document it well enough, there are still big holes [23:39] New features. Not just bugfixes! [23:39] I would not want to ask a less experienced person to build a release yet :-( [23:39] the build process? [23:39] y [23:39] The decision is simply to agree that next release is a minor where enhancements are allowed. [23:39] multitasking, CDot? [23:40] MartinCleaver: Kenneth did a proposal in the topic [23:40] vote: yes [23:40] * MartinCleaver checks again [23:40] I think we need to establish better what an "acceptable enhancement" is [23:41] otherwise some people might take it as carte blanche to include all sorts of changes [23:41] so we need a review process? [23:41] yes, that makes sense [23:41] vote: yes [23:41] i think we need a review process of new features [23:41] or at least some way of making changes highkly visible [23:41] create a Codev topic, explain the enhancement [23:42] let others give input [23:42] no, that isn't working [23:42] but who decides? [23:42] we don;t get input [23:42] perhaps express questionable features in some kind of "risk" evaluation? allow low / medium risk / low impact, deny high risk high impact [23:42] ArthurClements asked just the right question. [23:42] a report that shows all minor enh may be useful [23:42] I would rather have it driven by "customers" [23:42] A timeline when 4.1 would have to be finished would be great so that occasional programmers can see whether they've a chance to finish a contribution [23:43] CDot: continue [23:43] I would be quite happy, for example, to have to justify changes to Kenneth [23:43] or another similar user or set of users [23:43] CustomerTeam? [23:43] right [23:43] It is a balance. Someone need to want it. And someone needs to make it. [23:44] only, please don;t call them customers [23:44] we do have loyal users in Support [23:44] CriticalUserTeam [23:44] what's the operational difference betwen this non-named CustomerTeam and the "old" role of the CoreTeam? [23:44] with focus on kiss and unsability [23:44] unsanity, yes [23:44] the core team was a developer team [23:44] operational difference [23:45] "was"? [23:45] perhaps a new ReleaseManagerRole with a vote counting 4 or 5, other votes counting 1 .. for the cases where discussion ends up in non-agreement [23:45] (besides the fact that is the developer who will integrate the patch once approved) [23:45] and then changes the code :-) [23:46] well, strict rules don't apply [23:46] I think voting is not a good approach [23:46] I would be happy to submit to a board (whatever name it) [23:46] I would rather have a once-only review of ideas [23:46] me neither, we've seen voting periods extend over months [23:46] not a continuous process [23:46] as long as there is a mechanism to prevent the stagnation and frustration that happened pre-Dakar [23:46] We should start with the low hanging fruit. We should list the pending already coded - but not well tested - enhancements that are already in DEVELOP and agree which are merged in [23:46] right [23:46] i think that is a better approach, yes [23:46] we need a list of features [23:47] but the process stays the same [23:47] taht are in develop [23:47] fruit or not [23:47] most are no-brainers to put nto 4.1 [23:47] some need a discussion [23:47] there are very few features in DEVELOP [23:47] no-brainers make sense to add [23:47] so, the current ad-hoc process is "those in the meeting choose the features" [23:47] the question is how to identify the "some features" [23:47] that are not in 4.0.3 [23:48] Soronthar: yes [23:48] how about this: [23:48] Good. I can live with that [23:48] we create a report that shows the proposed features [23:48] too slow and ungainly [23:48] give 2 week time or so (until next meeting) for people to ask for a discussion of a feature(s) [23:49] we need to be able to *show* the features [23:49] so that people can try them [23:49] the features are in DEVELOP [23:49] and say "yes, i want that" [23:49] some of them, not all [23:49] the features are already in develop, so they are visible [23:49] and there is code in DEVELOP I do *not* want in a release [23:49] yes, that is why we need a vetting process [23:49] I would rather pull selected features into twiki4 [23:50] There are probably also some API stuff which is not "visible" on the user interface. And there is Merediths TAGS that we need to decide on. [23:50] separate the no-brainers from the ones that need a discussionm [23:50] I agree, we should avoid voting if possible .. but then we should be aware that we will de facto have a procedure that says "discuss / no commits until consensus" .. there's a difference between the daily added features / discussion and having an agreement on milestones set up front [23:50] hang on... this review process is actually rather simple [23:50] right, but new features can be in DEVELOP, then tested, before merged into TWiki 4.1 [23:50] it depends fundamentally on someone having a piece of work they would like to release [23:51] "the sponsor" [23:51] the review has to say "yes ok" or "no thats silly" [23:51] nothing more [23:51] there are also gray tones [23:51] "the release manager (group)" [23:51] it could be "yes, but we need to fix this and that" [23:51] fair point [23:52] * MartinCleaver has to leave in 10 mins [23:52] right now I am reluctant to use DEVELOP as an integration platform [23:52] it has had too many changes made in it without merging forward fixes from 4.0.3 [23:53] until someone puts the effort into mergeing those fixes, DEVELOP is essentially dangerous [23:53] agree [23:53] I would *not* base a reklease on it [23:53] (as I've experienced) [23:53] but features can be merged into TWiki 4.1 [23:53] any way to identify the 4.0.3 pieces that are not merged into develop? [23:54] for that reason i would rather wor forward on TWikiRelease04x00 [23:54] PeterThoeny: that is the work required to do a merge [23:54] I wroe a script to support that (to highlight the differences) [23:54] That is also my proposal. Current TWiki4 branch which is stable continues as the branch for 4.1 [23:54] but the main thing it shows is the difficulty of mreging [23:54] Lavr: good [23:55] so, basically, we proceed as follows: [23:55] someone has a proposal on Codev for an enhancement for 4.1 [23:55] they proceed to implement on TWikiReleas04x00 [23:55] knowing that they may be asked to revert it [23:56] The first thing in my proposal was that we all agree that we no longer need to reserve the TWIki4 branch as a bugs only branch because we do not plan a 4.0.4. And we plan a 4.1 in a not too distant future. [23:56] I support that. [23:56] casted mine [23:56] yes, kenneth's proposal is good [23:56] wait, can we interrupt and talk about martin's proposal now, since he has to leave [23:57] ok, so, we push features into 4.1, but carefully, knowing we may revert any of them [23:57] And the timing I propose - without any idea what is in 4.1 is to target August for beta and september for release. Just to give an idea of how much can go in. [23:57] ---+ 5. Removal of WebPreferences (an admin-oriented item) from normal users' left bars [23:57] this is a small item [23:57] martin, could you quickly elaborate? [23:57] (for "larger" features the sponsor should fork twiki4 branch and preferable use svk or similar to automagically merge twiki4 development to it often (daily)) [23:57] discuss in Codev -> raise Item -> do work [23:58] we do not need to discuss that in forum [23:58] hold on please [23:58] ok [23:58] that's right, next item is ok [23:58] lets give martin a chance [23:58] basically most people don't need to see the preferences of the web [23:58] so its info overload [23:58] see it if you are an admin [23:58] not otherwise [23:58] reduces clutter [23:59] oh, show it conditionally? [23:59] y [23:59] do we have IF member of AdminGroup? [23:59] I second Martin's suggestion - just remove it. [23:59] small change for kiss [23:59] shounds good [23:59] "sounds" [23:59] WebPreferences isn't changed, nor read, very often [23:59] any voices against? [23:59] ArthurClemens: I think I saw one in QuickMenuSkin [23:59] can consolidate on SitePreferences Session Time: Tue Jun 27 00:00:00 2006 [00:00] some people have vowed for graying out hidden items [00:00] If you look at the Preferences topic then there are some TWikiVariables in it. [00:00] Which are not documented elsewhere [00:00] but I would like to see it hidden [00:00] Lavr: The variables should get their VarFOO.txt topics [00:00] So that CDot's splitting of TWikiVariables makes more sense [00:00] i remember, colas does not like pages to look differently depending on users [00:00] SteffenPoulsen: good point on svk and personal branches [00:01] well children shouldn't see the same as adults [00:01] but this is a typical admin thingy [00:01] Neither do I actually. Exception is items visible only to adins [00:01] and marketing don't have the same interests as engineering [00:01] admins [00:01] not one user group vs another [00:01] +60 min [00:01] ok, I gotta run [00:01] byee [00:01] bye M [00:01] * MartinCleaver has left #twiki_edinburgh [00:01] ok, a.i. for martin: make the link conditional, and review other links for the same [00:02] But tailoring topics is so easy for anyone so I wonder why it is such an issue in the first place. [00:02] kenneth: good first time impression [00:02] we need to show the example sometimes [00:02] OK, FYI, the proposed enhancement I have for 4.1 is a restructured =configure= [00:02] i think it is good to show only relevant links [00:02] it is an interesting test-case [00:02] as it touches quite a lot of code [00:02] harald brings a good point to create VarFOO topics [00:03] for %BR%, %RED% etc [00:03] but as addition I would add a heading "Admin topics" [00:03] to make it clear to the admin as well [00:03] arthur: in every web? [00:03] to support colas [00:03] or just twiki web? [00:04] Actually it is TWikiPreferences that has the many variables. Not WebPreferences. [00:04] where admin topics are listed now [00:04] admins have the sitemap to access all webpreferences topics [00:04] it is about the left bar [00:04] i think it is ok to not show admin links in the sidebar [00:04] except for twiki web [00:04] but admins might want to add shortcuts [00:04] and bother noone [00:05] those admins who want shortcust can add them [00:05] the question is, do we need that by default? [00:06] our doc group will introduce a left bar with Newby topics, Skilled user topics, etc [00:06] :-) [00:06] yes, that is twiki.org specific [00:06] we can add 1 example for WebPreferences [00:06] A new TWiki ships with Main, TWiki and Sandbox. I have a hard time finding the issue of seeing a few links on the WebHome of those. New webs are normally created by WIPING the WebHome and start from scratch [00:07] yes, admin links on webhome is fine [00:07] admins can tailor it [00:07] so agreed to ermove admin links in sidebar? [00:07] "remove" [00:08] we can discuss this in detail later on [00:08] Absolutely [00:08] on Codev [00:08] On Side bar - No problem. I remove it on my TWikis also [00:08] do we need more discussion on this? [00:08] small change for kiss [00:09] if there are no objections i suggest to make it conditional [00:09] (I had missed the point that it was the default WebLeftBar we talked about. I thought about WebHome.) [00:09] _default, Main and Sandbox [00:09] not TWiki web [00:09] in distro [00:10] So minuted :-) [00:10] so, ok like this, or need more discussion? [00:10] objections? [00:10] no, unless more topics get involved [00:10] then we need more talk [00:10] ok, so lets do that [00:11] as for VarBR, VarRED etc [00:11] anyone takes that a.i.? [00:11] basically the ones in twikipreferences users might want to use [00:12] ...and related to that: Do we want to be VarXXX topics standalone? [00:12] can you explain? [00:13] Their "related" links in VarXXX topics don't work since they link to #OTHERVAR [00:13] instead of VarOTHERVAR or TWikiVariables#OTHERVAR [00:13] oic, good point [00:13] I was worried that you would hide the TWikiPreferences topic from normal view also in TWiki Web. If not then it is less an issue. [00:13] a simple solution is to only use TWikiVariables#OTHERVAR links [00:13] HaraldJoerg: add an Item; it's a 2 minute change [00:14] IMHO it ought to link to the varXXX topic [00:14] though..... what happens when the doc is extracted as a monolithic HTML? [00:14] do you still do that, Peter? [00:14] CDot: Exactly that's the problem! [00:15] If I use TWikiVariables, then linking to #othervar is just a browser issue [00:15] navigating in the big twikiavriables topic is much faster of links point to the same topic [00:15] there is another alternative [00:15] there is the big references manual that includes the important topics [00:15] which is to use one of our Publish technologies to generate the HTML [00:16] it includes only the twikivariables topic, not the individual VarXXX [00:16] so we are ok [00:16] no, we are not OK [00:16] can you elaborate? [00:16] because harald is proposing changing those links to link to the VarXXX topics [00:16] instead of anchor links [00:17] I'm not actually *proposing* that - I'd like to discuss what's better [00:17] since the VarXXX topics are not part of the monolithic HTML, the links will be broken [00:17] HaraldJoerg: hey, you stuck your head up.... ;-) [00:18] Yes, 'cause the current links are broken in VarXXX... [00:18] right [00:18] ok, that needs some more investigating [00:18] can we park this? [00:18] Yep. [00:18] +88 min [00:18] raise a topic in Codev [00:18] So does Harald take the action to investigate further= [00:18] ? [00:18]