<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style> ***: SEWilco2 has joined #tikiwiki <br> chealer has quit IRC (Remote closed the connection) <br> pascalstjean has quit IRC ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") <br> atlan_ has joined #tikiwiki <br> luminoso has quit IRC (Read error: 104 (Connection reset by peer)) <br> luminoso has joined #tikiwiki <br> atlan has quit IRC (Read error: 110 (Connection timed out)) <br> luminoso has quit IRC (Read error: 104 (Connection reset by peer)) <br> luminoso has joined #tikiwiki <br> luminoso has quit IRC (Read error: 104 (Connection reset by peer)) <br> luminoso has joined #tikiwiki <br> luminoso_ has joined #tikiwiki <br> luminoso has quit IRC (Connection reset by peer) <br> luminoso_ has quit IRC (Read error: 104 (Connection reset by peer)) <br> luminoso_ has joined #tikiwiki Tikiwiki|bot: New Forum Posts: Creating centered or aligned lists - http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=35005 ***: chip__ has joined #tikiwiki <br> atlan_ has quit IRC (Read error: 110 (Connection timed out)) <br> luminoso_ has quit IRC (Read error: 104 (Connection reset by peer)) <br> luminoso_ has joined #tikiwiki <br> btiffin has joined #tikiwiki <br> luminoso_ has quit IRC (Read error: 104 (Connection reset by peer)) <br> luminoso has joined #tikiwiki <br> Caarrie is now known as Caarrie|sleeping CIA-56: tikiwiki: 03pkdille * r22629 10/trunk/ (4 files in 3 dirs): [MOD] lesser magic deployment to blog admin template. Btw, recovering a pref (feature_blog_mandatory_category) which was lost in r17625. Will be backported to proposed <br> tikiwiki: 03pkdille * r22630 10/branches/proposed/templates/tiki-admin-include-blogs.tpl: [partial bp/r22629][FIX]admin blogs: Recovering a pref (feature_blog_mandatory_category) which was lost in r17625 ***: pkdille has joined #tikiwiki <br> btiffin has quit IRC (Remote closed the connection) Tikiwiki|bot: New Forum Posts: Something like ATTACH that uses file galleries - http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=35006 ***: PrezKennedy has quit IRC (Read error: 131 (Connection reset by peer)) <br> PrezKennedy has joined #tikiwiki <br> FrankP_german has joined #tikiwiki <br> gezza has joined #tikiwiki <br> Tikiwiki|bot has quit IRC (Read error: 104 (Connection reset by peer)) CIA-56: tikiwiki: 03sylvieg * r22631 10/trunk/templates/ (18 files): [FIX]smarty: inclose with double quotes incase the translation has a quote ***: Tikiwiki|bot has joined #tikiwiki <br> nelek has joined #tikiwiki nelek: hello <br> how can i add a google ad block a module block? i tried creating a user module and put the javascript code in but it just showed empty ***: Caarrie|sleeping has quit IRC (Read error: 104 (Connection reset by peer)) <br> Caarrie has joined #tikiwiki sylvieg: nelek :http://doc.tikiwiki.org/Module+adsense&structure=Documentation ***: luminoso has quit IRC ("Leaving") <br> jonnyb has joined #tikiwiki <br> jonnyb has quit IRC (Client Quit) <br> gezza has quit IRC ("Page closed") <br> Caarrie is now known as Caarrie|away <br> changi|bed is now known as changi|trip <br> pascalstjean has joined #tikiwiki luciash: <u>nelek</u>: use {literal} around the JS code pascalstjean: I've been trying to install Trunk. everything goes well during installation. But Tiki gives me error saying that my DB might be corrupt when its time to access site. Any ideas why this is happening? BTW Branch 3.0 installed just fine so I know that MySQL is running properly. Thank you all in advanced luciash: hi pascal <br> fresh install or upgrade ? pascalstjean: new install <br> I have an old Trunk install online that works fine when I SVN Update <br> but I have a presentation next week and looking to deploy Locally incase internet is Unstable luciash: hm, i haven't tried fresh mysql install recently <br> can you check your mysql ? ***: gezza has joined #tikiwiki luciash: if any db tables are corrupt ? <br> you can repair them if your mysql reports and db table as corrupt during check pascalstjean: any tips on how I can check for corrupt tables? I'm not very familiar with MySQL Administration but if you have a link somewhere I'm sure I can figure it out luciash: <u>SQL</u>: check table_name; <br> repair table_name; <br> iirc <br> but phpMyAdmin maybe have some tool to do that pascalstjean: is there a way to recursivly to check all tables in one command? <br> SQL check *.* or something? luciash: i have no idea... i only remember when using mysql console i was always warned about corrupt tables when i logged in... <br> it's long time ago though i had this pascalstjean: ok I'll check it out. Thanks luciash: since then i don't like mysql for corrupting a lot on one of my sites ;) <br> ☕ <br> re <br> but imho this is rare for fresh installs... i spell a bug <br> i smell, even <br> :) ***: jonnyb has joined #tikiwiki pascalstjean: agreed, I just repaired all tables and still getting the same results. Looks like a bug CIA-56: tikiwiki: 03jonnybradley * r22632 10/trunk/lib/core/lib/Perms/Reflection/Global.php: [FIX] Prevent tiki_p_admin being removed from Admins ***: larryg has joined #tikiwiki larryg: @luciash - thanks for your assistance with my <Find> problem yesterday. As an experiment, I opened at trial account on a different hosting service, and uploaded identical files and data.. My size-related Find and Multi-Print problems disappeared! ***: shawnadler has joined #tikiwiki <br> SEWilco2 has quit IRC ("Leaving.") gezza: polom <br> is dev down? jonnyb: p2 <br> i was just wondering that - so i guess it is :( gezza: :( <br> it is down quite often ***: SEWilco2 has joined #tikiwiki gezza: also trying to upload some pics to community site, but upload to file gallery gives me blank page <br> hmm, category browsing too jonnyb: i was just trying to get to Tiki4 marclaporte: <u>gezza</u>: changi & amette & ohertel are sysadmins for *.tw.o domains jonnyb: other pages seem ok... ***: jonnyb has quit IRC () luciash: <u>larryg</u>: np, i hope you figure it out for your server ***: larryg has quit IRC (Ping timeout: 180 seconds) gezza: when I make svn update for trunk I always get for libjquery "External failed" - how can I fix this? marclaporte: gezza, there is a command to ignore externals (it won <br> 't fix, but at least, you'll be able to continue) ***: luminoso has joined #tikiwiki gezza: <u>marc</u>: thanks, I am using tortoise on vista, is it a setting here? actually it continues for a few lines after the error <br> so I think it is not stopping marclaporte: no idea about tortoise <br> but I think it's a cool name gezza: <u>marc</u>: :) ok <br> <u>marc</u>: I created an "Assigned To Group" field in the wishlist tracker and would like to populate it with the names of the communty teams <br> what would be the best way to do? create on dev or in community and move via intertiki? <br> or? ***: gezza_ has joined #tikiwiki <br> gezza_ has quit IRC (Client Quit) marclaporte: gezza : all groups are created on the community site <br> You could make a group TeamAll and include all the Team* groups <br> stuff will propagate via InterTiki <br> BUT <br> I think you a feature request here <br> (interesting) <br> someone asked me about this yesterday <br> So you want a short list of people in group X to assign stuff to gezza: yes <br> just checked on dev <br> the list of groups <br> i dont see there the groups of community <br> the idea would be that "Assigned to person" is a member of the "Assigned to group" ***: btiffin has joined #tikiwiki gezza: i wanted to make a group selection item in the tracker and limit the selection options to the teams of two marclaporte: gezza : please create groups on dev with the same names than on community site <br> and group membership should transfer automagically gezza: <u>marc</u>: i see, so intertiki does not replicate groups, only memberships? marclaporte: looks like it <br> and perms can be different on each site <br> gezza : I do not know how you can limit the selections to members of a group (ex.: assigned to), but I hope it's possible <br> If not, please make a wish gezza: just checked, on dev intertiki group import setting is limited to "Registered,Admins,Developers,DevTwoAdmins,Security" marclaporte: ah <br> good catch gezza: is it ok to remove? <br> if it wont mess things up.. :) marclaporte: just add what you need <br> I guess you want them all :-) gezza: :) marclaporte: I don't think it'll mess up, but we'll find out soon enough gezza: yes, so I leave it empty <br> than everything should come over <br> everything = all groups of community :) ***: grobda24 has joined #tikiwiki grobda24: Is this a known bug. My YouTube vid load when previewed but not in the full article ... http://mindfreedom.org.uk <br> ? <br> I have tried {literal} tags as suggested in the docs but it does the same. I would really like to get this video to embed marclaporte: what is the exact code you are using? ***: gezza has quit IRC ("Page closed") grobda24: marclaporte, {FLASH(movie="http://www.youtube.com/v/OmnzbevlRaA",width="560",height="340")}{FLASH} ***: ohertel has joined #tikiwiki <br> ChanServ sets mode: +o ohertel ohertel: Hello! :) ***: jonnyb has joined #tikiwiki marclaporte: oliver! ohertel: switching tw.o to t4 today? or done already? CIA-56: tikiwiki: 03pkdille * r22633 10/trunk/ (7 files in 2 dirs): [MOD] removing functions in loops. Better fix than r22541. Thks Sylvie ohertel: Do we have a 4.0 branch or is this trunk yet? marclaporte: I don't know, but it would I think it would be good to shake out bugs <br> <u>ohertel</u>: no branch4, but I think we should do. We have two problems/decisions to do before <br> 3.3 needs to be released urgently because 3.2 has fatal error if you use any of the 15-20 secure plugins <br> #2 release script needs to be checked to see if we can call branch with the name "branches/4" instead of "branches/3.0" <br> #3 : we need to decide about branching strategy <br> branch now, and merge script to trunk (My current favorites) grobda24: marclaporte, any ideas ? marclaporte: that looks fine <br> does it work in a wiki page? ***: chealer has joined #tikiwiki marclaporte: <u>grobda24</u>: works here: http://tikiwiki.org/Test grobda24: marclaporte, hmmm ... it being displayed on my front page within the articles plugin marclaporte: the articles feature? grobda24: The YouTube vid is in an article <br> marclaporte, your test is on a wikipage marclaporte: ok <br> which version grobda24: v3.2 marclaporte: so ohertel, what do you think? <br> <u>grobda24</u>: http://info.tikiwiki.org/article76 <br> something is working CIA-56: tikiwiki: 03pkdille * r22634 10/trunk/lib/ (6 files in 4 dirs): [MOD] better not to have functions in the second argument in a for loop grobda24: marclaporte, oh :| marclaporte: <u>grobda24</u>: my focus is releasing Tiki4, so I won't look into this further. If you can prove bug on Tiki4, I will look into it grobda24: I am in debug mode from a previous problem <br> k marclaporte: <u>grobda24</u>: I see that plugin works in "heading zone" <br> but not in body <br> http://info.tikiwiki.org/tiki-read_article.php?articleId=76 <br> grobda24 : please check if already a bug report. If not, please add: http://dev.tikiwiki.org/Articles chealer: <u>pascalstjean</u>: please show the actual error message grobda24: marclaporte, thanks for noticing that, I will try and make a bug report marclaporte: I will delete test article <br> grobda24 : as a workaround, you could try: put video in wiki page. and from article, use pluginInclude to include wiki page grobda24: ok ***: ohertel has quit IRC ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") pascalstjean: <u>chealer</u>: System Error <br> The following error message was returned: <br> SQLSTATE[HY000] [2002] Invalid argument CIA-56: tikiwiki: 03jonnybradley * r22635 10/trunk/ (2 files in 2 dirs): <br> tikiwiki: [FIX] Fixed show disabled feature switch, no 2nd remove button on globals & few minor label changes <br> tikiwiki: [ENH] Basic copy/paste perms function ***: SEWilco2 has quit IRC (Read error: 110 (Connection timed out)) CIA-56: tikiwiki: 03jonnybradley * r22636 10/trunk/tiki-objectpermissions.php: [FIX] Only paste perms once (for safety - you can always copy again) chealer: <u>pascalstjean</u>: is that all? jonnyb: so... we branchin' ? :) ***: SEWilco2 has joined #tikiwiki pascalstjean: <u>chealer</u>: yes chealer: <u>pascalstjean</u>: what makes you think your database would be corrupt? pascalstjean: try doign a fresh install you will see the same. I've treid 3 fresh installed on 3 different systems. Desktop, Laptop and Online Account. luciash: do i see it correctly that trunk stays main devel and we need proposed branch for branches/4 and quality team will continue to backport proposals from trunk until Tiki4 is released ? -: jonnyb checks http://dev.tikiwiki.org/How+to+release jonnyb: hi luciash - yes, nyloth's keen we should keep two 'proposed's luciash: and when will branches/3.0 become discontinued (not "supported") ? <br> and hi jonny :) <br> is he really keen about it or is it kind of british humour ? ;) jonnyb: nyloth? decidedly not a brit :) <br> i can't seem to find a "how to branch" luciash: <u>jonnyb</u>: there's a script for that in devtools jonnyb: i'm guessing i just do: php doc/devtools/svnbranch.php branches/4.x on a clean checkout of trunk - whaddayathink? luciash: yes jonnyb: mainly (well, 2 things) - are we ready? and should it be called branches/4.x ? <br> i like 4.x better than just 4 luciash: i guess it is the same as on http://dev.tikiwiki.org/tiki-index.php?page=SVNTips#Experimental_branches <br> i am not ready until i know where to commit then ;) jonnyb: that's where i was looking for inspiration <br> me neither! <br> shall i just have a go? <br> the plan (i think) for 3.x is to keep it going (apart from security stuff) until 5.0 luciash: ah, ok, so then we really will have two proposed branches <br> are you fine with that ? <br> i thought 3.3 will be the last :-p <br> after 4.0 is released jonnyb: should be - i think, but lots of people are upgrade-averse chealer: <u>jonnyb</u>: 4.x is no more meaningful than 4, so why not choose the shorter form? :) jonnyb: 3.3. should go out asap, cos 3.2 had Bad Things in it :( <br> i like the mysteriousness of the .x ;) luciash: well, maybe i prefer 4.x too as it indicates there will be some more releases like 4.0, 4.1, etc. chealer: <u>jonnyb</u>: see for example http://websvn.kde.org/branches/KDE/ (4.3 is a KDE version series) jonnyb: also "4" is just an integer, doesn't seem significant enough luciash: 4 sounds like an error <br> :) jonnyb: yy ***: grobda24 has left "Leaving" luciash: bad things ? i thought only one bad thing ;) jonnyb: well yes, one Bad Thing (but affecting 20 or so plugins) luciash: yep yep <br> i thought it's only for fresh installs but from the recent chat here i realized upgrades with "secured" plugins are also affected ? jonnyb: there almost should be a 3.2.1 (if we had the resources) <br> just the tiki.sql fix luciash: resources ? <br> ah, but there are gonna be another quality approved goodies in 3.3 so it can't hurt ;) jonnyb: ok, i'll give it a go... <br> indeed luciash: jonnyb seems impatient tonight ;) jonnyb: resources would be more nyloths, in this case luciash: well, anybody can release if he takes the release manager role <br> he|she jonnyb: well, i keep adding more stuff to it - just can't resist! luciash: brb, just need to take a shower jonnyb: and it's now 9 days overdue luciash: btw, i need to add two things to trunk but i haven't found solution yet :( <br> so i would maybe prefer if you branch after shower ;) <br> or some hours later *g* <br> now i am really afk, bbl CIA-56: tikiwiki: 03jonnybradley * r22637 10/branches/4.x/: [BRANCH] Creation, trunk 0 to 22636 jonnyb: cooo - was just testing whether i'd made the right fix to the branch script ;) <br> looks like it worked then - sorry luciash CIA-56: tikiwiki: 03jonnybradley * r22638 10/trunk/doc/devtools/svntools.php: [FIX] Allow 'x' as the second part of stable branch names (e.g. branches/4.x) jonnyb: <u>marclaporte</u>: are you there? it seems i have done branches/4.x - i was mainly testing a fix to the branch script, but it worked! I had intended to check properly with you and anyone else concerned before actually doing it... CIA-56: tikiwiki: 03sylvieg * r22639 10/trunk/ (4 files in 2 dirs): [MOD] lesser magic deployment (1 tab of fgal) <br> tikiwiki: 03jonnybradley * r22640 10/branches/4.x/tests/example.txt: [TEST] Checking the new 4.x branch chealer: I don't suppose there is a "forward-annotate" tool, for example to find when a line disappeared from a file? jonnyb: <u>chealer</u>: not that i know of, but i usually find blame takes too long... chealer: <u>jonnyb</u>: ok. well, yeah, but blaming is so cool :) jonnyb: i'm getting "Could not find previous merge. Impossible to merge automatically." on the merge-back-to-trunk script (branchupdate.php) luciash: re jonnyb: hi luciash - i seem to have made 4.x <br> (testing the script) luciash: fine, then it will be not in 4.x what i wanted... jonnyb: not necessarily luciash: i have to figure out myself jonnyb: we could delete it and do it again later luciash: heh jonnyb: but i can't get trunk to merge changes from it luciash: you need to tag the revisions to make the merges work, no ? jonnyb: oh? (not sure what that means) <br> i get: Could not find previous merge. Impossible to merge automatically. luciash: at least we tagged at the CVS times, not sure if we still do with SVN jonnyb: tagging is for releasing i thought luciash: when i merged i did with tagging jonnyb: i'll try subclipse... luciash: seems it's looong time i last merged anything using Eclipse ;) <br> see in Aptana if there are some tags in the history jonnyb: i've done a fair bit on merging experimental (very mental) branches luciash: okay, seems it's not necessary then anymore... don't know what your error could be else then <br> maybe the .x still somewhere jonnyb: could be -: jonnyb checks for other sneaky preg_replacements CIA-56: tikiwiki: 03chealer * r22641 10/trunk/templates/ (header.tpl tiki-edit_translation.tpl translated-lang.tpl): [FIX] HTML special chars encoding marclaporte: polom <br> jonnyb : me reads log about branching jonnyb: poloms <br> just thinking about kil'ing it - sending a mail to svn list... marclaporte: <u>jonnyb</u>: : 4.x is better than 4.0 , but why not just 4? jonnyb: 4 just looks like an error (as luciash said) marclaporte: ok, I am reading log <br> <u>luciash</u>: ; we have to decide about http://dev.tikiwiki.org/Version+lifecycle <br> ok, I am with chealer on this that short is better. But 4.x is very good too. And as long as it's no longer 4.0 :-) chealer: yeah :) luciash: polom marc marclaporte: so I am ok with your & luciash's choice <br> let's just get this show on the road! <br> now <br> about merging <br> 1- how can we have people fix on branches/4.x for the next three weeks, and those fixes merged to trunk via script? jonnyb: think i'm stuck - the script doesn't want to merge from 4.x to trunk luciash: btw, i was searching the branch or not to branch page but couldn't find it (as anonymous) marclaporte: bad search engine? <br> or perms? luciash: <u>marclaporte</u>: on dev and community <br> <u>marclaporte</u>: i don't know, is the page with perms ? marclaporte: http://www.google.com/search?rlz=1C1GGLS_enPT291CA306&sourceid=chrome&ie=UTF-8&q=to+branch+or+not+to+branch+tikiwiki luciash: <u>jonnyb</u>: is it needed ? <br> <u>jonnyb</u>: i mean it's not the same as experimental branch <br> <u>jonnyb</u>: isn't it ? <br> <u>jonnyb</u>: i expected not to merge to trunk from that branch <br> i thought we will do the other wayy around actually, as with proposed branch jonnyb: <u>luciash</u>: i thought that's what we did the past few times (merge from branches/x.x to trunk?) marclaporte: and (this is the most important issue) 2- We need to be able to delete some stuff from branches/4.x and not have those deletes propagate (because we can give more time for these things to evolve) BUT all the same time, we want fixed to branches/4.x to be merged up How do we tell the system to merge up certain revisions but not others. And how do we keep track? jonnyb: v good questions marclaporte luciash: ok, then i must be wrong again (as usual)... i just thought it would make more sense than trying to force everyone to work on branch 4.x chealer: I agree with luciash - no merges to trunk jonnyb: hmm - i thought the idea was to get everyone focussed on the new release? luciash: weren't we focused enough in trunk ? ;) marclaporte: both options are valid -: jonnyb thinks food might help - will be lurking luciash: we are all focused on 4.x release, i thought the branching will be just clear signal that in that branch will go no more new features marclaporte: but in the past, we made branches/3.0, and merged to trunk luciash: yes, we did, but i am not sure it worked very well (sylvie's merge pain)... i think the way as with proposed branch works better marclaporte: proposed branch is very time consuming as well <br> I think backporting is more expensive than forewardporting <br> but I am not saying which one we should choose <br> I am OK with both. We just need to agree luciash: but on the other hand only good things get in and we can be sure we don't release something unfinished / weak / unstable marclaporte: LP and CoE have some Tiki5 commits to do. So trunk would be nice for them <br> in any case, I think the only debate is "when" <br> a few days before, at the latest, we need to have branched <br> so we need to make sure script can work with 4.x instead of 4.0 <br> tks jonnyb for looking at this <br> I know many people will say: "Use Git", but this is not one of the options at the moment. These people should promote this idea at the appropriate time :-) luciash: heheh marclaporte: :-) luciash: also you can clean and kil as you need in the branch 4.x if we go the backport way <br> while keeping things on track in trunk marclaporte: yes <br> so maybe relaxed procedure for backports would be in order (not QT) <br> and QT starts at 4.0 release luciash: yup, sounds fine to me marclaporte: now, we need to remove some stuff from trunk. I can tell people, go put your stuff in experimental <br> I am just wondering what is most efficient / least overhead luciash: so branch 4.x will be something like "pre-proposed" where quality team can rollback if anything inapropriate gets in, but they don't have to approve and backport to stable 4.x yet <br> at time of 4.0 release, this branch will become stabilzed (what 3.0 is now) and new proposed for 4.x will be created marclaporte: luciash : so basically, this is a 3rd proposal. Can you explain here: http://dev.tikiwiki.org/How+to+release#To_branch_or_not_to_branch <br> A benefit is that more of us will learn to use QT scripts <br> but it's got to be easy & quicky. Because there will be 500, maybe 1000 commits still until 4.0 <br> So if we add overhead & complexity to each of these commits, we lose people and code <br> However, the good thing is QT backport scripts are (I think) intended to be very chirurgical (I want to backport this commit, but not this one) luciash: ah, now i know why i couldn't find the page ;) marclaporte: you thought it was the name? <br> refactor to new page if you think it's better :-) <br> I love wikis luciash: yep, i searched by page name marclaporte: refactoring is a prime example of why I love wikis. In Tiki4: you could add "To branch or not to branch" as an alias to the page, and find it in page name search (Thanks to Alain Desilets) chealer: yes, commit approvals are orthogonal to the question of merging to trunk or not luciash: <u>marclaporte</u>: is it not possible to add alias in 3.x for that already ? marclaporte: yes, you can add alias. But won't be in page name search chealer: it's possible to work on branch 4 first, but it creates issues: 1. that's different from what we're used to. 2. it's in the order of things that fixed are done on trunk first. 3. nobody has to do merges. <br> one advantage is that there's no need for everyone to commit to 2 places. luciash: ah chealer: but I see no reason why the procedure should be different before and after release luciash: but i can create a page and put redirect ;) marclaporte: <u>chealer</u>: tks for your updates on http://dev.tikiwiki.org/DevTips luciash: <u>chealer</u>: yep, as I see it, devs will have self-interest to backport what they create and test on trunk if they want it ever released ;) marclaporte: <u>luciash</u>: , yes for redirects, but we try to avoid, as it's "pollution" luciash: ok <br> sure, redirects are better in .htaccess <br> (when necessary) -: marclaporte hopes to manage .htaccess from Tiki one day :-) chealer: it also avoid merge bugs, since it's much easier for the person who fixed a bug to verify the backport than for whoever happens to be doing a merge marclaporte: so chealer, can you vote here: http://dev.tikiwiki.org/How+to+release#To_branch_or_not_to_branch ? <br> and any arguments for/against any <br> and add arguments for/against any luciash: i am editing, wait pls marclaporte: <u>chealer</u>: I am worried indeed about double merge chealer: <u>marclaporte</u>: what do you mean by double merge? marclaporte: oups, double work because of need to merge chealer: <u>marclaporte</u>: I have an opinion on how to handle a branch, but I didn't really form an opinion on when to branch. it's also been a while since I saw a major Tiki release happen. marclaporte: ok chealer: <u>marclaporte</u>: personally, as long as I don't do stuff which can't I can't commit (and I don't think that will be the case), I have no issue with branching later. I could list myself as undecided... luciash: saved the page, you can add under benefits pf erging from branch to trunk if you have some ;) <br> <u>marclaporte</u>: i created "To merge or not to merge" there instead ;) marclaporte: hahahaha luciash: bbl chealer: :) <br> <u>luciash</u>: I don't understand "only tested things (bugfixes, UI enhancements) get in from trunk (no new features after feature freeze/branch creation) and we can be more sure we don't release weak / untested / unstable" <br> <u>luciash</u>: isn't that just a benefit of branching early? luciash: re <br> depends on the stream which direction it flows ;) <br> if backporting way then yes, but before we thought only about merging way back to trunk <br> so i preferred to branch as late as possible chealer: <u>luciash</u>: I see that could make sense explaining why you prefer to have to the flow in this direction, but it doesn't make sense to me as an argument. someone who prefers merging to trunk could argue that he would be for an earlier merge if fixes flow from branch to trunk, and use the same argument. <br> <u>luciash</u>: I see that could make sense explaining why you prefer to have the flow in this direction, but it doesn't make sense to me as an argument. someone who prefers merging to trunk could argue that he would be for an earlier merge if fixes flow from branch to trunk, and use the same argument. luciash: i prefer it also because we do like that with proposed and also that i am not forced to switch to another branch when i have some work-in-progress in trunk ;) chealer: <u>luciash</u>: yes, I agree with those reasons luciash: only problem remains about the manpower split ;) if the devs feel comfortable to contribute to the release or are forced to work on working on finishing the release <br> *forced to work on make the release happen in time <br> anyway i think there are much more benefits now, than disadvantages ***: changi|trip has quit IRC (Read error: 110 (Connection timed out)) CIA-56: tikiwiki: 03chealer * r22642 10/trunk/ (3 files in 2 dirs): <br> tikiwiki: [ENH] change translation module to new module style (modules-doc). <br> tikiwiki: [FIX] HTML special chars encoding <br> tikiwiki: [FIX] colons inside tr blocks <br> tikiwiki: [FIX] undefined show_translation_module notice <br> tikiwiki: show completeness even if 0% ***: marclaporte has quit IRC ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") <br> jonnyb has quit IRC ("I am going outside... I may be some time...") <br> FrankP_german has quit IRC ("Nettalk6 - www.ntalk.de") CIA-56: tikiwiki: 03pkdille * r22643 10/trunk/ (5 files in 3 dirs): [MOD] lesser magic deployment to forum admin template sylvieg: :-( itis the third time I have problem with upgrade .. people put their files in files/ - and somebodu created files/ <br> and svn .. whatever does not support diff with 'funny' files luciash: hrmph <br> <u>sylvieg</u>: but i see no files in there coming from svn in trunk sylvieg: files/templates/listpages/smarty-tikiwiki-1.0-shortlist.txt <br> is a regular file luciash: just index.php and templates/ <br> ah <br> haven't noticed <br> svn blames lph sylvieg: so for only one little file .. we have to deal with tons of svn diff problems :-( <br> people usually create dir in the tiki root - not outside tiki root luciash: but i have cron svn upping here with no problem... what diff problems you have ? sylvieg: thre is some files - no idea what they are - svn bugs luciash: i see only this txt here sylvieg: my problem is that people were used to use files/ as the directory for files <br> but now it is a svn dir luciash: yep, and it conflicts ? sylvieg: I have no idea - why svn stops on some files there <br> no conflicts - just svn is not happy <br> and stops <br> to do any diff - status luciash: hmm sylvieg: so each time I have to move the files directory somewhere else <br> to have sn running luciash: weird, it doesn't happen here sylvieg: but for ONE file in files/.. bad naming choice in tw <br> me too - should be some micosoft file svn does not like.. luciash: any command you want me to try ? sylvieg: it is the 3- sites it happens to me.. luciash: ah, linux here, sure sylvieg: svn status- or svn diff luciash: works fine on linux sylvieg: - just a lot of energu to spend on this for only one bad naming files in tw luciash: sorry i cannot reproduce your problem, no windows svn here -: sylvieg pretty close to move smarty-tikiwiki-1.0-shortlist.txt to antoher dir sylvieg: files-tw ***: marclaporte has joined #tikiwiki <br> ChanServ sets mode: +o marclaporte luciash: yes, i would say tiki_files (as we have tiki_tests), but we still need index.php in files/ in SVN, nope ? sylvieg: it is just that people have the bad idea to put all their files in files under tikiroot - seems to be a 'natural' way luciash: <u>sylvieg</u>: or you just can put 6*, etc. in your svn:ignore like me <br> usually people don't run SVN on their productivity servers <br> so putting 6* in svn:ignore will help you on these 3 sites <br> or whatever the files start sylvieg: yeh worse - they copy their files to the new upgrades files luciash: so just put * in your svn:ignore properties for that files/ dir ;) <br> <u>sylvieg</u>: try svn propset svn:ignore * files/ sylvieg: yes but if I do that - the lph file will not be sync anymore... luciash: yep, but is it that important file ? sylvieg: no idea :-) you get the point luciash: i am not sure if it applies on subdirs moreover <br> the svn:ignore <br> i think it applies only on files in files/ <br> not in subdirs <br> you can try put there test.txt next to the lph file and svn status if it will say something about the file <br> after you have the svn:ignore set ***: luminoso has quit IRC (Read error: 110 (Connection timed out)) luciash: hold on sylvieg: btw luciash is there a 4 branch - I was not looking a t my computer all teh day <br> and guy you talk a llt <br> lot luciash: jonny just tested it <br> the creation <br> it worked with branches/4.x but he got some problems when he tested merging to trunk (which i think we don't need) <br> :-p sylvieg: we need merging 4 to trunk a lot of time <br> why nelson the guy who did all the branches since.. was not on this one luciash: depends what way we decide to go sylvieg: does nyloth and other will support the amount of work? <br> I will probably not <br> tiki4 is not ready luciash: you don't have to approve anything, just rollback if you're not happy ;) sylvieg: about 10 problems I know about that must be solved luciash: do you like merging to trunk more ? i thought you don't like merges hell sylvieg: merging 4 to trunk if done often is ok <br> we lost the history - but.. <br> backport trunk to 4 - is ... time consuming luciash: please write the benefits at http://dev.tikiwiki.org/How+to+release#Benefits_of_merging_from_branch_to_trunk <br> i see only one - the faster devel sylvieg: I do not understans luciash: http://dev.tikiwiki.org/How+to+release#Benefits_of_backporting_from_trunk_to_branch <br> i listed my idea there sylvieg: :-( guys you need to feel the pein to merge or to backport luciash: i did backports to proposed and it is not that bad when one does it with his own code he knows <br> worse is merging code you don't know <br> i think <br> so what is worse for you ? merge to trunk or backport to branch ? marclaporte: forward ports are less expensive than backports though luciash: <u>marclaporte</u>: i don't understand sylvieg: sorry it is funny to have the opininon of people who never pratice merge - backport - cherrypicking . Utopia is an ideal word is very good marclaporte: say we have 50 commits to manage luciash: <u>sylvieg</u>: i did merge in the past <br> not recently though, true sylvieg: between a tikix and a tikitrunk - I did for at least 3 releases - it is 1 hour each day marclaporte: Each merge is a potential regression. And regressions in branches/4.0 are more expensive/problematic than regressions in trunk. <br> and in theory, all fixes in branches/4.0 are supposed to go in trunk (until the code diverges too much) sylvieg: but in trunk I get nothing from svn log <br> why spending so much time time to have sn log in tiki3 marclaporte: so what is your preference sylvieg? sylvieg: and only automaitc merge in tikitrunk <br> dev need to know <br> we do an automaic merge proposed to back <br> we do a cherry picking form back to trunk ***: Caarrie|away is now known as Caarrie sylvieg: me as a dev wants to know easily the history - me as a production site does not care if somebody checks to commit luciash: please correct me, what is bad on fixing in trunk, testing in trunk and if it's good backport to branch 4.x ? <br> you think devs will not listen ? sylvieg: and me as a dev will feel painfuul to have a 'almost' release more than a month luciash: will just keep working on trunk and not to care about backporting and someone else will have to do it ? sylvieg: because we do not have history in trunk svn log - with the way we do today <br> I am a dev - I want a COMPLETE svn log on the latest <br> today I have 'automatic merge' the time a pre-release is released <br> .. so - my idea - is to do automatic merge proposed - to tikix <br> and do 'cherry picking' from'a almost a pre-released version to trunk <br> if pre-released does not exist - fine for me <br> but he latest pre-released was 1 or 2 months -: sylvieg needs to work on a svn script to go from tikix to trunk sylvieg: /me needs to convince nyloth to spend all his energy to the future and not to the past -: luciash never understood the 'automatic merge' when one needs to check it carefully and resolve conflicts manually sylvieg: we are VERY LUCKY bacport to tikix works - because of nyloth <br> thx to him luciash: yep, and i like it sylvieg: automatic merge is a pain when it lats more than ... a month <br> <u>luciash</u>: why do you need to ned the history/log is a version that is released luciash: or when someone indents the code or when ... or when ... ;) sylvieg: .. whatver luciash: sorry ? <br> i am sorry i didn't understand the "why do you need ..." sylvieg: ...... we only need a script that commits each commit from tikix to trunk - and through away automatic merge - luciash: <u>sylvieg</u>: but i believe you know what fits you best :) i just don't know what you prefer yet... so you prefer force everybody to switch to branch 4.x and work there and do "automatic merge" often ? sylvieg: if devs an do 'individual' merge to back and trun nice