<!-- 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&amp;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&amp;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&amp;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 &lt;Find&gt; 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 &amp; amette &amp; 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 &amp; 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 &amp; 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&amp;sourceid=chrome&amp;ie=UTF-8&amp;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 &amp; quicky. Because there will be 500, maybe 1000 commits still until 4.0
   <br> So if we add overhead &amp; 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