[21:54] I've allotted times to all the agenda items [21:55] currently they total 100 minutes [21:55] of course they're only a guide [21:56] PeterThoeny, do you want me to facilitate again? [21:59] -->| Drusilla (n=Drusilla@proxy.wildwoodweb.net) has joined #twiki_edinburgh [22:00] Sam, you have *got* to be joking. [22:00] who me? [22:01] Drop the last agenda item. 10 minutes each isn't long enough for the other items [22:01] hi all [22:01] we have 3 choices [22:01] 1) [22:02] 1) stick rigidly to the times allotted [22:02] -->| CDot (n=crawford@crawfordcurrie.plus.com) has joined #twiki_edinburgh [22:02] 2) give more time per item and drop some of them 3) be honest and don't call it a 90 minute meeting [22:03] 1 seems rather pointless, since all that will happen is that the topic winds up being pushed to the next meeting. [22:03] allocate less for the review of prev items [22:03] |<-- AndreU has left freenode (Read error: 104 (Connection reset by peer)) [22:03] -->| Lavr (i=Lavr@0x535b29eb.albnxx17.adsl-dhcp.tele.dk) has joined #twiki_edinburgh [22:03] ok, which sub-item looses time? [22:04] item review is just a status check, we can try to make this in 15 min [22:05] I don't think we can [22:05] plugin dev model takes most time probably [22:05] And anything that involves Sven being here has to be taken offline [22:05] -->| SteffenPoulsen (n=step@cpe.atm2-0-1151196.0x503f90c2.arcnxx11.customer.tele.dk) has joined #twiki_edinburgh [22:06] 3 and 4 are two related aspects of the same issue [22:06] hi andre, steffen, kenneth [22:06] hi all [22:06] Hi guys and girls [22:06] I propose that if an item don't have a related thread in Codev at least a week long, to drop it after 10-15 minutes and start the thread to discuss out-of-band [22:06] create the topic, I mean [22:07] Given that at least 10 minutes has been allocated to *everything*, that's kind of meaningless, I'm fraid [22:07] And 10 minutes for brainstorming is futile [22:07] Brainstorm in the topic, discuss the results in a meeting [22:07] app packaging does not need that much time, but 15 min would be good [22:08] masically get people involved, then take offline for a week [22:08] s/masically/basically/ [22:08] lets clear one think up to start with, am I facilitating this meeting? [22:08] Lynnwood isn't here, so I guess so [22:08] yesm please :-) [22:08] and who is taking the minutes? [22:09] ok, before we start is someone taking minutes? [22:09] snap [22:09] lynnwood has an other commitment at this time [22:09] * SteffenPoulsen looks up the round robin order of minute takers [22:09] -->| AndreU (n=AndreU@dslb-082-083-221-075.pools.arcor-ip.net) has joined #twiki_edinburgh [22:09] ah, it's me! [22:09] thanks SteffenPoulsen [22:09] we are set then, thanks :-) [22:10] ok, review the agenda [22:10] ---++ 1. Review Previous Action Items (15 minutes) * develop.twiki.org server move (0 minutes) * TWiki 4.0.3 (5 minutes) * Moving twiki.org to TWiki 4 (5 minutes) * Tinderbox: (5 minutes) ---++ 2. TWiki 4.0.3 Release (10 minutes) ---++ 3. Single Branch Plugin Development (45 minutes) ---++ 4. Plugin API policy (10 minutes) ---++ 5. TWiki Application Packaging (10 minutes) [22:10] anything to add? No? ok. good [22:10] ---++ 1. Review Previous Action Items (15 minutes) [22:10] * TWiki 4.0.3 (5 minutes) [22:12] away you go folks..... [22:12] Not shipping tomorrow [22:12] you're pre-empting item 2 [22:13] http://develop.twiki.org/~develop/cgi-bin/view/Bugs/ReleaseBlocker has 9 required, 21 urgent [22:13] Oh. I thought you said 4.0.3 [22:13] Sorry [22:13] yes, but we're only reviewing what we did last meeting [22:13] Sorry! [22:13] we get to talk about the release date later [22:13] Lavr, you did the list, anything that needs a point? [22:14] I have not updated the list but... [22:14] only applicable is "Check for cosmetic patches to configuration files" [22:14] there are many new urgent and the number of "normal" is growing and growing [22:14] The list of cosmetic to critical files is done. It was not bad at all [22:15] good [22:15] Merge=n/a doesn't mean not for 4.0.3 [22:15] There was one thing in the sandbox that Cdot reverted or fixed so we are in a good shape currently with not making it too difficult to upgrade from 4.0.2 to 4.0.3 [22:15] 2207 has been solved via another item, I believe [22:15] gr8, let's return to new bugs under 2 [22:16] Sam? [22:16] yes? [22:16] that means, next item [22:17] ok, sorry [22:17] * Moving twiki.org to TWiki 4 (5 minutes) [22:17] i exhanged some e-mail with the isp on ougoing e-mail issue [22:18] not really their field, because it is a config question on solaris box [22:18] i sent an e-mail to sven asking if he can help out [22:18] this is beyond me [22:18] isp also confirm that tests look ok [22:18] i will ask sven again [22:19] he is most knowleable on sys admin [22:19] other than that we should be pretty much ready to switch [22:19] all perl libs are installed [22:19] sounds great .. looking forward to see this last issue resolved [22:20] * doc update of twiki web topics (Kenneth, Lynnwood, Arthur will help) * 50% done [22:20] any progress on that? [22:21] the test install is using twiki04 web at the moment [22:21] we can do the switch with that [22:21] and later once twiki web is ready, switch over the web [22:21] i did some work on docs not last week, but week before [22:22] so doc update is not a showstopper for twiki 4 switch [22:22] ok, lets move on then [22:22] * Tinderbox: (5 minutes) [22:23] excellent [22:23] I've had too little time to put any work in that [22:23] i have not yest asked the company [22:23] btw, this is not fastmetrics i am going to ask [22:24] put down "big corporation" for now [22:24] wbniv is setting the initial stuff up at the moment, I will coordinate efforts again, hopefully this week [22:24] -->| HaraldJoerg (n=haj@dialin-212-144-016-055.pools.arcor-ip.net) has joined #twiki_edinburgh [22:24] Peter: so mysterious, sounds great [22:24] i can't be more specific at this time [22:24] Sam, you can proceed [22:24] next, unless questions [22:25] ---++ 2. TWiki 4.0.3 Release (10 minutes) [22:25] SteffenPoulsen: i've got a checkout on your box and have started working on it [22:25] sorry, was afk [22:25] wbniv, no prob - yep, hopefully more to state at next meeting :-) [22:25] Drusilla, you can talk about release dates now ;) [22:25] I rather doubt it's shipping tomorrow [22:26] Next? [22:26] no, we have to set another date don't we? [22:26] Agree with Dru. Too many open bugs. It seems most of us had a busy week with what brings food on our tables [22:27] Lavr: please point out the bugs that you think are blockers: http://develop.twiki.org/~develop/cgi-bin/view/Bugs/ReleaseBlocker [22:27] I saw the translation mail go out (forget who sent it, sorry) but haven't seen any responses [22:28] There are many urgent open now compared to when we normally say we can release. But not more than what normally takes a week to fix. [22:28] and test the fixes [22:28] So delay a week and review next monday [22:28] (22:27:14) CDot: Lavr: please point out the bugs that you think are blockers: http://develop.twiki.org/~develop/cgi-bin/view/Bugs/ReleaseBlocker [22:29] That means walking through them all. [22:29] CDot: Start with 2226 [22:29] on your own, yes. Just give me a list of numbers. [22:29] I'm not sure if the search on ReleaseBlocker isn't too wide [22:29] but I'm not familiar enough with what should/shouldn't be in the release, or considered a blocker, that I didn't know how to filter it more [22:30] SamHasler: it's ok, Not perfect, but a lot better than what we had before. [22:31] 2204 is not a showstopper, it is an operator error [22:31] nevertheless, tiki should be producting a better error message [22:31] So it's acceptable to have TWiki break like that? [22:31] s/tiki/twiki/ [22:32] "*foo*" is an invalid regex [22:33] 2204 is max low priority. And maybe should be discarded. [22:33] It's still not professional to be met with a screen like that [22:33] And regexes are notoriously difficult to get right. [22:34] low or medium, either is fine [22:34] is it twiki or apache that gives us that error message? [22:34] it's an enhancement in my view, especially as we are talking releasing [22:35] Apache [22:35] twiki [22:35] ? [22:35] Triggered by twiki [22:35] probably returned by grep [22:35] lets move on [22:35] And only happens when scope=topic [22:35] next bug or next agenda item? [22:35] next bug worth mentioning [22:36] 2226 [22:37] That was covered already [22:37] Lavr: is that the whole list? [22:37] I did not go through them all before the meeting. I noticed there are more than usual. Did you? [22:37] yes [22:38] my conclusion was: 2226 [22:38] all others are not, IMHO, release blockers. [22:38] That's fine, although how many bug-fix releases are we planning on making? [22:38] I see that many are develop only. That distorts the picture a bit. Are they actually urgent??? [22:38] * SamHasler notes that we're past the 10 minutes of allotted time for this item [22:39] Drusilla: as many as we can. But I think we should accept that currently, 2226 is the only "blocker" [22:39] and that once that is fixed, the release can go. [22:39] It's still considered a blocker? [22:40] I thought you said it was better but not perfect. [22:40] 2207 should be closed. [22:40] The fix of INCLUDE make the problem go away [22:40] Yes. [22:40] I will close it now. [22:41] I see ML is already there :-) [22:41] * Drusilla has fast fingers [22:41] ok, so stretching the point, even 2226 is not a blocker [22:41] as it isn't critical, just cinfusing [22:41] confusing [22:42] usability issue, what's arthurs opinion? [22:42] It gives a lot of users problems. [22:42] look, either state it is a blocker, or not [22:43] And it should be possible to fix it simply by removing the list from the template since it has no function anyway. [22:43] I think it is a blocker. [22:43] ok, thanks. Release blocked by 2226, no other blockers. Next item? [22:43] And I propose to fix it the simple way. Ie. not make a lot of code to try and make a bad fix but remove the list from the template [22:44] so if there aren't any blockers, when is the release? [22:44] sorry, only 2226 [22:44] if we're lucky, perhaps arthur is thinking of something already [22:45] are we releasing tomorrow? next week? reviewing next week? [22:46] what are reasons not to delay? [22:46] will we need a meeting next week for that, (considering peter wanted meetings every 2 weeks) [22:46] No, but we'll need a meeting for the stuff that isn't dealt with from today's agenda [22:46] let's do the build tomorrow and have it out for testing .. previous releases suffered from to little time from build to release [22:47] PeterThoeny: momentum [22:47] SteffenPoulsen: good point [22:47] i'm ok with that [22:47] and fix for e-mail bugs [22:47] ok, if will is ok, then lets do a build tomorrow [22:47] e-mail bugs? [22:47] don;t call it 4.0.3 yet to avoid confusion [22:48] 4.0.3-rc1 ? [22:48] two e-mail bugs in 4.0.2 [22:48] that make a bad impression [22:48] (and of course from the fact that only a few of us had the time to actually try it out .. hope more of us will have the chance to take it in for a test ride this time) [22:49] Perhaps there should be a topic created for every build [22:49] 1843 has also been hanging too long now. We have plugins released without ,v files and when people update the plugin settings topic the original version is gone. [22:49] Then feedback can be accumulated there [22:50] Lavr: if it gets fixed in the next couple of days, it gets fixed; but is not a blocker [22:50] Drusilla: that's what Bugs web should be used for, really [22:50] so we have a single picture of the state of the release [22:50] instead of spreading it [22:51] So each release should be entered as into Bugs? As, um, what? Enhancement? [22:51] no, no. take offline. [22:51] 4.0.3-rc1 sounds ok, for distribution in irc / perhaps twiki-dev only? [22:51] We keep on pushing 1843 - why the rush to get 4.0.3 out and dismiss urgent bugs this time? [22:52] so we do a build tomorrow, what's the timeline after that? [22:52] Same with 2012 which must be candidate to the most common problem on #twiki [22:52] 1843 is a good one, i'd like to have fixed as well [22:53] So would I. [22:53] We have so many that pass by #twiki and have problems with locked topics and need some command line help to fix it. [22:53] this is the right thinking, customer focus [22:53] so 2012 is a must too from this perspective [22:54] it also helps us reduce support load [22:54] ok, let's just cancel 4.0.3 until those two are fixed? [22:54] Agreed. Let's move on? [22:54] actually, i'd prefer a build for testing since there have been quite a few code changes [22:55] you can use SVN, surely? [22:55] so build & test, and in parallel fix the few issues we identified [22:55] It is still worth doing an rc1 asap to verify build, test cases etc [22:55] Will estimates 4-24 hours per build. That's a lot of time for him to invest [22:55] would be good to have a shared rc1 as common ground [22:55] 'xactly [22:55] I don't see a point in doing an rc1 with blocker bugs still in the codebase. [22:56] but if you want one, so be it [22:56] Will shouldn't have to blow off up to a day just to have to do it again for sure [22:56] it doesn't take a day. [22:56] if noone is going to run it it's not going to help any, that's right .. [22:56] it's not good to have too many test builds, it disenthuses your testers [22:56] CDot: the first time it does! ;-) [22:57] and most of the work is saved during the next time the build is run (manifest fixing etc) [22:57] wbniv: sure; but you have done it once already :-) [22:57] We're running way over... [22:57] and there are issue sto be resolved, such as creating diffs [22:57] SamHasler: ? [22:57] CDot: what does that mean? i do builds from nothing--not the previous build [22:57] so an early build helps reduce the risk of further delay [22:57] DRu: 1881 seems to need your attention. [22:57] Maybe to either merge fix or close. [22:58] CDot, I'm waiting for resolution on this [22:58] It's also a bug in NatSkin, last I looked [22:58] ok, look, the name "RC1" suggests something pretty powerful [22:58] RC == "Release Candidate" [22:58] Like: all blockers fixed [22:58] it suggests you are prepared to release that build [22:59] but you are saying there are blockers [22:59] so it *cannot* be RC1 [22:59] 4.0.3pre1 [22:59] simply call it something else [22:59] wbniv: fine [22:59] sounds good [22:59] done [22:59] ---++ 3. Single Branch Plugin Development (45 minutes) [23:00] so no new tentative date for 4.0.3 - date set at next meeting? [23:00] oh, date, i'd say shift by one week (but still build tomorrow) [23:00] ok, noted [23:01] And we declare STRING FREEZE now? [23:02] sensible, yes [23:02] or anything pending? [23:02] nope, don't think so .. let's hit 3 [23:03] ok [23:03] on plugin branch, may be rafael can explain his proposal first? [23:03] dunno, will 2226 have text changes? [23:03] or just deletions? [23:03] * Soronthar waits [23:03] ok. my proposal [23:04] seems like you have two proposals [23:04] the first one: Having one branch for DEVELOP, one for plugins, one for each release family and one tag per release. [23:04] tag of what? [23:04] neither DEVELOP, nor the release branches and tags have plugins in them [23:04] It's an svn term [23:05] http://twiki.org/cgi-bin/view/Codev/SingleBranchPluginDevelopment#One_branch_for_all_plugins_one_b [23:05] plugins only recide in the plugins branch. [23:05] tag == label in CVS [23:05] I know what a tag is, don't worry, you answered my question [23:05] basically Core is developed in DEVELOP and plugins in PLUGINS. [23:06] when a major release is made, then DEVELOP is copied to a branch. [23:06] when a minor or patch release is made, a tag is created [23:07] the second one it's simpler: Have a MAIN branch with twikiplugins in it. [23:07] that represents the latest releaseable code. [23:07] DEVELOP (with twikiplugins in it) for the next version [23:08] but the checkin access to DEVELOP should be only for core developers. [23:08] release branch and tags remain the same as today. [23:08] why is there a need to have plugins also in DEVELOP? [23:08] So, for all practical effects, plugins are being developed in only one branch: MAIN. [23:09] Because they take advantage of feature in develop [23:09] Plugin authors may merge from MAIN to DEVELOP to test new versions of the plugin with the latest code. [23:09] but this version should NEVER be released from DEVELOP [23:10] Plugins should only be released from MAIN, and we can enforce that. [23:10] at release time, a branch is created for the last state of MAIN, and then DEVELOP is merged over to MAIN (the core code) [23:10] and Core plugins. [23:11] the second proposal sounds more simple [23:11] this way, developers are always sure that the latest releaseable is in MAIN, no matter if it's Dakar, Edin, funafutil or whatever [23:11] Yes. Simpler is better. [23:12] but means also that we change back to the two branch model we had before [23:12] (just asking) [23:12] no... DEVELOP/twikiplugins is a playground for extension developers. [23:13] what was the reason to switch to the one branch per release method for core code? [23:13] Easy management. [23:14] For example, when Edin comes out, it's easier to issue a patch upgrade to Dakar [23:14] or several patch releases of Dakar, if needed [23:14] so if we switch back to two branch model, do we lose some of the easy management? [23:14] now you lost me. [23:14] perhaps I missunderstood you [23:14] i recall that sven was a big supporter for the one branch per release [23:15] yes, I misunderstood. [23:15] we need one branch per release for the Core code. [23:15] Today we have defacto TWO so we do not really loose anything. And once we have a DEVELOP, TWiki4x1 and TWiki4x0 with 4.1 being the released production release - TWiki4x0 will defacto be a dead tag. [23:16] now i am confused, how can we get that with just MAIN and DEVELOP? [23:16] You rarely see any projects that keep more than two alive. [23:16] you missed the part: Soronthar release branch and tags remain the same as today. [23:16] to sum up [23:17] it's MAIN, DEVELOP, one branch per release family and one (read-only) tag per release. [23:17] which is reverting to how we worked during dakar dev (before release) [23:17] i am fine with that, just want to point out [23:18] and are released plugins in the release branches and tags? [23:18] yep. but are readonly (no commit allowed) [23:18] and let people respond who wanted the one brnach per release [23:18] read-only in the tags, yes. what about the release branches? [23:19] if we want to enforce one branch for plugins, they should be read.only [23:19] so how do you make a build with updated plugins? [23:19] if we want to "encourage" one branch for plugin, but leaving the option for extension developers to branch their plugins, then they should be writable [23:19] I do not understand why there is both a MAIN and a release branch per release. That sounds complicated. [23:20] Lavr: If MAIN is DAKAR, there will not be a DAKAR branch [23:20] When MAIN is Edin, then the dakar branch is created with it's latest state [23:20] Raf knows a lot about SCM. I trust his judgement. [23:21] Then the difference between today and the new proposal is nothing but names? [23:21] so, after edin is out, dakar is a branch for maintenance releases? [23:21] well.. sort of. [23:21] But there is a big difference semantically [23:21] MAIN is not a moving target [23:21] it's always "The latest releaseable" [23:22] i understand, yes, one branch to work by default [23:22] today, the latest releaseable is TWiki04. tomorrow will be TWiki05 [23:22] i do not really mind one way or the other for core code [23:22] Like TWiki4 today. But with a generic name that makes is more clear that this is where plugins reside and are developed. [23:23] Lavr: bingo! [23:23] so if the release branch is read-only for plugins, how do you make a build with updated plugins? [23:23] * Soronthar should learn to comunicate better [23:23] what i do not see though how this addresses the one code base need for extensions [23:23] PeterThoeny: There is one codebase for extensions: MAIN [23:23] We need to address the next item to entirely deal with that, i believe [23:24] oic, lock down release branches for extensions [23:24] SamHasler: Extending the MANIFEST and DEPENDENCY files capabilities. [23:24] so they can gather the core plugins from MAIN. [23:24] from a specific revision? [23:24] yep [23:24] ok, gotcha [23:25] what is the policy do develop extension in MAIN vs DEVELOP? [23:26] MAIN should be "releaseable", DEVELOP is "bleeding-edge/experimental" [23:26] |<-- AndreU has left freenode ("This computer has gone to sleep") [23:26] of course, that might mean you have to revert a plugin to a previous state, make changes, commit and then revert it back if you're doing a patch release after unstable changes have been made to it [23:27] so we do have two branches for extensions [23:28] how can that address " Discourage API changes, e.g. promote a stable Plugin API / TWiki applications API"? [23:28] but releases are not made from DEVELOP [23:28] What I find is confusing today is that ALL plugins are more than one place. If only those few plugins that are actively "bleeding edge" developed are in DEVELOP and otherwise fetched from MAIN then it becomes more clean and clear what is going on. [23:28] and only core developers have accesss ot it. [23:29] And promote not doing it unless there is a bleeding edge reason for it [23:29] kenneth has a good point [23:30] as far as most plugins developers are concerned, DEVELOP doesn't even exist [23:30] Only Core developers will have access to DEVELOP. Plugins are only released from MAIN. [23:30] it is for core experimentation [23:30] overall i like the idea of all extensions in MAIN [23:30] that should be enough [23:31] And API does change in the sense of extending, just not in the sense of changing the arguments of existing API. [23:31] we need to easy the life of developers for having "backward compatible" plugins, but that's another thread altogether [23:32] right [23:32] it looks like everyone is gathering round this proposal, can the rest of the discussion be taken offline? is there anything that needs resolving now? [23:32] i see that it can be tempting for developers to enhance core and extensions, and introduce new apis & deprecate apis just because it is cleaner to do so [23:33] tempting because DEVELOP and MAIN are separate [23:33] Of course we're introducing new API. The product isn't dead. [23:34] That doesn't mean we change the arguments to existing API [23:34] so how can we address that? [23:34] but that's inevitable (having two branches) if you want to keep the stable version while building the next generation. [23:34] this is not the forum for this discussion. The agendum related to branches, not APIs. [23:34] So let's move to the next item [23:34] So [23:34] crawford: this is the _core reason_ why i brought up the subject in the first place! [23:35] Then we should move to the next agenda item and come back to this one [23:35] action item: I'll modify the topic to reflect only the proposal of MAIN and DEVELOP [23:35] so we can discuss on the implementation details [23:35] do we all agree? [23:35] Aye [23:35] as long as we find a way to reduce the risk of changing apis [23:35] which we will discuss now [23:35] ---++ 4. Plugin API policy (10 minutes) [23:35] and get a promise from the developers [23:35] <--| CDot has left #twiki_edinburgh [23:36] so? Action item for me? [23:36] and move on? [23:36] Write up the final proposal. [23:37] A simple business rule should be enforced. If you change the API in a non-backwards-compatible way you also have to update all the broken plugins that have been actively developed within the last two years. [23:37] which bring us to point 4) [23:37] please? [23:37] No one has any intentions of changing the API in that way, except to deprecate API with plenty of notice [23:37] kenneth: this does not address the issue of all those in-house built plugins [23:38] but a good start [23:38] No. But it would make people think twice. [23:38] and incentive not to brak things [23:38] s/brak/break/ [23:39] rafael: so you prefer proposal 2 orver proposal 1? [23:39] yep. less changes to the existing infrastructure [23:39] ok [23:39] we have not heard from crawford yet on his proposal [23:39] he left [23:40] What proposal? [23:40] http://twiki.org/cgi-bin/view/Codev/SingleBranchPluginDevelopment#One_branch_to_rule_them_all_and [23:40] I think he's fine with Raf's proposal [23:40] Having talked to him about it [23:41] Crawford latest looks very much like Rafs proposal 2. [23:41] the more i think of what kenneth proposed, the more i like it [23:41] shall we introduce this business rule? [23:41] -->| CDot (n=crawford@crawfordcurrie.plus.com) has joined #twiki_edinburgh [23:41]