IRC Archive for channel #xwiki
Last modified by Vincent Massol on 2012/10/18 19:19
00:04 <abusenius_> has joined #xwiki
00:04 <abusenius> has quit
03:46 <abusenius_> has quit
04:20 <DrLou> has quit
07:51 <vmassol> has joined #xwiki
08:01 <mflorea> has joined #xwiki
08:13 <vmassol> has quit
08:28 <sdumitriu> has joined #xwiki
08:29 <tmortagne> has joined #xwiki
08:37 <vmassol> has joined #xwiki
08:56 <vmassol> agents are stuck
08:56 <vmassol> good morning
08:56 <vmassol> stopping them
08:57 <+tmortagne> vmassol: too many open files
08:57 <+tmortagne> for the trunk one at least
08:57 <vmassol> has alex increased them already?
08:57 <+tmortagne> no idea I asked him but...
08:57 <@sdumitriu> On a3, yes
08:57 <+tmortagne> it's agent2
08:57 <vmassol> yes on a3 but that's a1 & 2
08:58 <vmassol> tmortagne asked on friday
08:58 <vmassol> for a1 & 2
08:58 <vmassol> have we checked which application has the files open?
09:01 <arkub> has joined #xwiki
09:01 <+tmortagne> speaking of which
09:01 <+tmortagne> who wants to be a m... build manager ?
09:02 <sburjan> has joined #xwiki
09:03 <vmassol> 810 opened by java process
09:03 <vmassol> 433 by apache
09:04 <vmassol> tmortagne: btw when you read the web-inf/lib files do we release the handle you have on them? (just to be sure ;))
09:04 <+tmortagne> trying wit no build running
09:04 <vmassol> (with the extension manager I mean)
09:05 <+tmortagne> vmassol: I think yes, and we read this since a long time now, I will check
09:05 <+tmortagne> what agent are you looking at ?
09:05 <+tmortagne> agent2
09:05 <vmassol> yes
09:05 <+tmortagne> stoping all build on it just to be sure
09:06 <vmassol> 1816 open files on agent2
09:06 <+tmortagne> ok stopped
09:06 <+tmortagne> (stopped jenkins itself actually)
09:06 <+tmortagne> to see if there is something wrong on the server
09:06 <vmassol> there's still a java process running on agent2
09:06 <+tmortagne> how many do you have now ?
09:07 <vmassol> could be xwiki
09:07 <+tmortagne> hmm
09:07 <vmassol> 1816
09:07 <vmassol> it's tomcat
09:07 <+tmortagne> actually hudson is still running it seems
09:07 <vmassol> yes
09:08 <+tmortagne> there is a lot of deleted files open
09:08 <+tmortagne> lucene
09:09 <+tmortagne> though that was fixed
09:09 <+tmortagne> looks like we are getting the lucene bug about deleted files
09:10 <vmassol> tmortagne: where do you see that? I only see the files in web-inf/lib
09:10 <vmassol> (for the java process)
09:10 <vmassol> (and the jdk ones)
09:10 <+tmortagne> I get lots of things like
09:10 <+tmortagne> "java 12277 hudsonagent 549r REG 8,2 109787 50711541 /home/hudsonagent/hudson_root/workspace/xwiki-enterprise-tests/xwiki-enterprise-test/xwiki-enterprise-test-ui/target/xwiki-enterprise-jetty-hsqldb-3.2-SNAPSHOT/jetty/work/Jetty_0_0_0_0_8080_xwiki__xwiki__5alevh/lucene/_4.nrm (deleted)
09:10 <+tmortagne> "
09:10 <+tmortagne> with lsof
09:11 <vmassol> sudo lsof | grep lucene | wc -l
09:11 <vmassol> gives me 12 lucene files
09:11 <vmassol> that's not a lot
09:11 <+tmortagne> I have certaininly a lot more than 12
09:11 <+tmortagne> maybee not anymore
09:11 <+tmortagne> recehcking
09:11 <vmassol> sudo lsof | grep WEB-INF | wc -l
09:12 <vmassol> gives 624
09:12 <vmassol> that's a lot
09:12 <+tmortagne> yep I still have a lot
09:12 <vmassol> you're on agent2?
09:12 <vmassol> what command to do you execute?
09:12 <+tmortagne> just execute lsof and look
09:12 <+tmortagne> there is more that 12 for sure
09:13 <vmassol> can you run my command?
09:13 <vmassol> if you just run lsof you'll get thousands of entries
09:13 <+tmortagne> 182
09:13 <+tmortagne> just executed you command
09:13 <+tmortagne> are you sure you are on agent2 ?
09:13 <vmassol> ok so it must be fluctuating which is good
09:13 <vmassol> 10 now
09:13 <vmassol> hmmm
09:13 <+tmortagne> it's not fluctuating for me
09:13 <+tmortagne> I always get the same number
09:13 <vmassol> I did a ssh agent2.myxwiki.org
09:14 <vmassol> ah myxwiki
09:14 <vmassol> what is agent2 on myxwiki?
09:14 <vmassol> hmmm
09:14 <+tmortagne> hudson is agent-2.maven.xwiki.org
09:14 <+tmortagne> s/hudson/jenkins/
09:16 <jvdrean> has joined #xwiki
09:21 <+tmortagne> 1110 files opened total on agent2 it seems
09:21 <+tmortagne> so not enough to beat 2048
09:22 <vmassol> tmortagne: what's ulimit -n on agent-2
09:22 <+tmortagne> hmm
09:22 <+tmortagne> 1024
09:22 <vmassol> so that's why...
09:22 <+tmortagne> but ales just said he restarted it
09:22 <vmassol> ask him to check again maybe? :)
09:23 <vmassol> guys we need someone for this week as Build Manager: http://dev.xwiki.org/xwiki/bin/view/Community/BuildManagerRoster
09:23 <+tmortagne> actually he did not restarted it since I would not have xwiki otherwise
09:23 <vmassol> if nobody volunteers we'll pick a committer at random :)
09:24 <vmassol> role is described at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBuildManagerRole
09:28 <+tmortagne> I see 888 files opened on agent2 which seems a lot to build commons
09:28 <+tmortagne> agent3 sorry
09:29 <+tmortagne> 314 jar files
09:29 <Enygma`> has joined #xwiki
09:31 <vmassol> tmortagne: when XE executes that creates a lot more open files I think
09:32 <+tmortagne> sure but it's still a lot IMO
09:32 <evalica> has joined #xwiki
09:32 <+tmortagne> maybe jenkins is expensive too
09:32 <+tmortagne> in any case 1024 is certainly not enough seeing that
09:33 <+tmortagne> but what I don't understand is why now ?
09:33 <vmassol> it's not just now, been happening for some time already
09:34 <vmassol> maybe we were close to the limit and we added some jars to web-inf/lib for ex
09:34 <vmassol> we also upgraded some libraries
09:34 <vmassol> in 3.1
09:34 <+tmortagne> it happen all the time theses days and it's rare enough before for me to not remember any of them
09:34 <vmassol> also we moved to jdk6
09:34 <vmassol> the jdk opens a lot of files
09:34 <vmassol> too
09:34 <+tmortagne> yea
09:34 <+tmortagne> anyway hope it's not a leak
09:35 <+tmortagne> (checked EM btw it's properly closing the stream)
09:35 <vmassol> I'd like to know who hold a lock on the web-inf/lib jars
09:35 <vmassol> is it just the jdk
09:35 <vmassol> or is our app
09:35 <vmassol> s/is/is it/
09:36 <+tmortagne> probably the jdk maybe jetty too
09:47 <+mflorea> tmortagne: would you agree that is relatively easy to write a transformation that transforms WordBlock to a link if the word matches an existing tag?
09:47 <@sdumitriu> Yes
09:47 <+tmortagne> mflorea: yes it should
09:48 <+mflorea> ok, thanks, I suppose we don't have something like this already?
09:48 <@sdumitriu> But I'm not sure that's what you need, mflorea
09:48 <vmassol> mflorea: we do
09:48 <+tmortagne> write a transformation in general is very easy, then there is the transformation itself
09:48 <@sdumitriu> Yes, the CamelCase
09:48 <vmassol> I have coded wikiwords transofrmation for ex
09:48 <+mflorea> vmassol: that's different I think
09:48 <vmassol> sure
09:48 <vmassol> but very close
09:48 <+mflorea> I'm looking for links to tags
09:49 <+mflorea> yes, I agree
09:49 <vmassol> for tags you'll need to
09:49 <+tmortagne> yep it's more or less the same logic
09:49 <vmassol> cache the tags list
09:49 <vmassol> write a listener to intercept tag operation to refresh your cache
09:49 <+mflorea> indeed
09:58 <@sdumitriu> tmortagne: Remote observation test failing: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-observation-remote/277/testReport/org.xwiki.observation.remote/TCPROMTest/testSerializableEvent/
09:58 <@sdumitriu> Can you look into it?
09:58 <+tmortagne> sdumitriu: yes I know
09:58 <+tmortagne> I tested lots of think looks like I will have to come back to custom files on for ci
09:58 <+tmortagne> s/think/things/
10:13 <vmassol> tmortagne: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-observation-remote/278/ :)
10:14 <+tmortagne> vmassol: that's weird this build does not contains my last modification
10:14 <+tmortagne> should have failed like the one before it
10:14 <@sdumitriu> Indeed
10:16 <+tmortagne> or maybe it's just failing on some agent(s) since I still don't understand why it's failing
10:16 <+tmortagne> so if true it mean it's failing on agent3 and not on agent1
10:17 <+tmortagne> tying next build to agent3
10:20 <+tmortagne> at least I know some configuration works on agent3 since 3.1 build well oon it
10:20 <+tmortagne> s/oon/on/
10:20 <+tmortagne> lets see this as a good things, force me to find some configuration that will build well on more environment, always better for tests ;)
10:24 <+tmortagne> cool looks like I found it this time
10:24 <+tmortagne> so it's working with localhost and not with 127.0.0.1
10:25 <+tmortagne> jgroups is pretty sensible
10:34 <vmassol> sensitive not sensible ;)
10:34 <vmassol> (tmortagne)
10:34 <vmassol> sensible means almost the opposite :)
10:36 <+tmortagne> lets say ticklish then :)
10:44 <vmassol> ok ulimit should be ok now on all agents
10:53 <cjdelisle> has joined #xwiki
10:58 <Denis> has joined #xwiki
11:16 <vmassol> btw myxwiki.org has restarted 2 or 3 times over the weekend….
11:16 <vmassol> not sure why yet
11:17 <vmassol> btw this is strange:
11:17 <vmassol> com.xpn.xwiki.XWikiException: Error number 3202 in 3: Exception while reading document name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [CDATA[ */
11:17 <vmassol> document.observe('dom], type = [WIKI], parent = [null]]]
11:17 <vmassol> Wrapped Exception: Error number 3301 in 3: Exception while switching to database CDATA[ */
11:17 <vmassol> document.observe('dom
11:17 <vmassol> Wrapped Exception: Incorrect database name 'CDATA[ */
11:17 <vmassol> document.observe('dom'
11:17 <vmassol> at com.xpn.xwiki.store.XWikiHibernateStore.loadXWikiDoc(XWikiHibernateStore.java:811) ~[xwiki-platform-oldcore-3.1-20110602.173052-162.jar:na]
11:17 <vmassol> should be ok
11:18 <vmassol> seems ot be coming from the rendering of a page
11:18 <vmassol> in xwiki 1.0 syntax
11:18 <vmassol> at com.xpn.xwiki.render.XWikiRadeoxRenderEngine.appendCreateLink(XWikiRadeoxRenderEngine.java:312) [xwiki-platform-oldcore-3.1-20110602.173052-162.jar:na]
11:18 <vmassol> at com.xpn.xwiki.render.filter.XWikiLinkFilter.handleMatch(XWikiLinkFilter.java:211) [xwiki-platform-oldcore-3.1-20110602.173052-162.jar:na]
11:20 <vmassol> hmm still
11:21 <vmassol> it's reading XWiki.XWikiPreferences
11:27 <fmancinelli> has joined #xwiki
11:33 <+tmortagne> vmassol: that's because xwiki/1.0 syntax is matching a lots of things as links as long as it find a [something]
11:34 <fmancinelli> has quit
11:34 <vmassol> tmortagne: indeed you must be right
11:34 <+tmortagne> it always produce bad things like that
11:34 <@cjdelisle> Hi all, I'd like to see if I can release just enterprise into nexus instead of dropping the whole repo and rereleasing everything.
11:35 <vmassol> it must be evaluating a text area on XWikiPreferences
11:35 <vmassol> cjdelisle: you're back cool! :)
11:42 <vmassol> node1 crashed again
11:46 <vmassol> there are quite a few threads blocked on
11:46 <vmassol> Â java.lang.Thread.State: BLOCKED (on object monitor)
11:46 <vmassol> at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
11:46 <vmassol> - waiting to lock <0x00000000ce5282b8> (a org.apache.catalina.loader.StandardClassLoader)
11:46 <vmassol> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
11:46 <vmassol> about 6-7
11:47 <vmassol> I see a lot of RUNNABLE threads though so I don't understand why it wasn't responding
11:48 <vmassol> hmmm
11:48 <vmassol> 27106 tomcat    20   0 1662m 1.2g  18m S   99 61.1 149:58.44 java Â
11:48 <vmassol> that's 99% cpu?
11:49 <vmassol> 27106 tomcat    20   0 1662m 1.2g  18m S  100 61.1 149:58.94 java      Â
11:49 <vmassol> ok so tomcat was eating all cpu apparently
12:08 <DrLou> has joined #xwiki
12:22 <abusenius_> has joined #xwiki
12:30 <abusenius_> is now known as <abusenius>
12:42 <abusenius> has quit
12:52 <mflorea> has quit
12:58 <@cjdelisle> sburjan: I just sent mail to the list about the re-release (into staging) of enterprise, some testing on that would be excellent.
13:10 <+sburjan> cjdelisle: I'll re-test the packages
13:33 <kwoot> has joined #xwiki
13:33 <kwoot> hello verybod. If I want to tweak pdf export to include a company logo, what should be the syntax to put in pdfheader.vm? would be soooo nice to know.
13:34 <@sdumitriu> HTML
13:39 <mflorea> has joined #xwiki
13:40 <kwoot> hello mflorea. Do you know the answer to this one? If I want to tweak pdf export to include a company logo, what should be the syntax to put in pdfheader.vm? would be soooo nice to know.
13:52 <@sdumitriu> kwoot: HTML
13:53 <@sdumitriu> HTML + Velocity
13:55 <+sburjan> cjdelisle: packages work. just tested. I'm replying also on the list
13:56 <+mflorea> kwoot: you can start with:
13:56 <+mflorea> <img src="$xwiki.getSkinFile('logo.png')" alt="logo" />
13:59 <kwoot> cool!
14:00 <@cjdelisle> awesome, I also released manager, I'm not sure if you traditionally do any testing on that
14:02 <abusenius> has joined #xwiki
14:09 <kwoot> mflorea: this works nice but show only a logo in the content pages, after the title and after the toc page. Is there a way to get this logo on every page?
14:28 <+sburjan> cjdelisle: usually I don't get the chance only after the release. If you wait a few hours I could do that. Tomcat + mysql + war. I am unable to reply on the list due to technical issues
14:30 <@cjdelisle> I think a final release can wait a few hours.
14:34 <+mflorea> kwoot: have you tried putting it on pdfcover.vm and pdftoc.vm also?
14:34 <+mflorea> note that I'm not an expert at this :)
14:35 <kwoot> i'?l give ut a try, Just thought maybe there is a global setting somewhere. Will hack the pdfcover and pdftoc instead. thanks!
14:38 <+sburjan> cjdelisle: just found that XEM Test machine doesn't have network access.. investigating
14:42 <+sburjan> cjdelisle: give me the staging links to the XEM builds
14:42 <+sburjan> zip + war
14:42 <@cjdelisle> they should be the same as the ones from the last email from thursday
14:43 <+sburjan> ok
14:44 <+sburjan> cjdelisle: something is not right or the name of the packages are changed
14:45 <+sburjan> I am expecting some file called: xwiki-enterprise-manager-mysql-3.1.zip, but I find a xwiki-manager-jetty-mysql-3.1.zip
14:46 <+sburjan> what am I missing ?
14:46 <@cjdelisle> that has changed as of 3.1
14:47 <+sburjan> ok.
14:47 <@sdumitriu> The new name is normal
14:48 <mflorea> has quit
14:48 <+sburjan> so basically now we have a package that bundles jetty in it ?
14:48 <mflorea> has joined #xwiki
14:50 <@sdumitriu> Ah, no
14:50 <@sdumitriu> Or yes?
14:50 <@sdumitriu> let me check
14:51 <@sdumitriu> Yes, we always had a jetty package
14:51 <@sdumitriu> xwiki-enterprise-manager-mysql-2.7.2.zip included jetty as well
14:52 <@sdumitriu> It doesn't mention -jetty because it's the only type of container distributed with XEM
14:52 <@sdumitriu> XE also has glassfish
14:54 <+sburjan> sdumitriu: yes, I got confused because it didn't had "jetty" in name until now :)
14:54 <+sburjan> also, didn't know we have a glassfish bundle too :)
14:56 <+tmortagne> it's based on a now old beta version of glassfish 3 if I remember well
15:00 <DrLou> has quit
15:07 <+sburjan> cjdelisle: managed to start XEM, I get a XWiki Enterprise 3.1.${buildNumber} in the footer
15:07 <+sburjan> so I guess something is not 100% right
15:07 <@sdumitriu> That's wrong
15:07 <@sdumitriu> The buildnumber should be removed
15:08 <@sdumitriu> Duplicated configs are baaaad...
15:12 <+tmortagne> version.properties file should be simply removed from XE since it's exactly the same version since 2.0
15:12 <+tmortagne> XEM
15:12 <+tmortagne> from XEM
15:13 <+tmortagne> taking care of it
15:14 <+tmortagne> *XEM-191
15:14 <+tmortagne> XEM-191
15:16 <@sdumitriu> Are you sure it's the same?
15:17 <+tmortagne> yes I'm sure, XEM is always based on the same XE version
15:17 <+tmortagne> and always released with it anyway
15:17 <@sdumitriu> Shouldn't it be XWiki Enterprise *Manager* 3.1 instead of XWiki Enterprise 3.1?
15:17 <+tmortagne> that has nothing to do with this file
15:18 <abusenius> has quit
15:18 <+tmortagne> this file contains a version not a name
15:19 <+tmortagne> the name part is in XWikiPreference if i remember well
15:20 <@sdumitriu> Right
15:22 <+tmortagne> cjdelisle, sburjan: fixed
15:24 <@sdumitriu> re-re-release?
15:25 <@cjdelisle> heh you saw my note taking the agent offline?
15:25 <@sdumitriu> Nope :)
15:25 <@cjdelisle> "Disconnected by CalebJamesDeLisle : re-re-releasing manager due to XEM-191"
15:26 <@sdumitriu> I guess only manager needs to be released this time
15:26 <@sdumitriu> enterprise is OK
15:26 <+tmortagne> cjdelisle: wait a bit, i'm rechecking something
15:27 <+tmortagne> cjdelisle: it's ok
15:28 <+tmortagne> (was checking if XEM web build was excluding version.properties file before putting its own)
15:40 <@cjdelisle> Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project xwiki-manager-web: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: basedir /home/hudsonagent/releases/xwiki-trunks/xwiki-manager/target/checkout/xwiki-manager-web/src/main/webInfResources does not exist
15:41 <@cjdelisle> I'm going to go get something to eat
15:42 <@sdumitriu> sburjan: I finished XWIKI-6504: Convert Panels application into syntax 2.0
15:42 <@sdumitriu> Can you check the next XE build to check it all works fine? Panels and panel wizard
15:47 <+tmortagne> cjdelisle: thanks weird, I'm checking
15:49 <+tmortagne> cjdelisle: should be ok now
16:01 <@cjdelisle> sburjan: released again...
16:10 <+sburjan> sdumitriu: of course
16:12 <+sburjan> ok cjdelisle ,so I'll have t o wait and re-install the XEM, right ? :)
16:13 <@sdumitriu> Why wait?
16:13 <@sdumitriu> Test now
16:13 <@sdumitriu> From the staging repo
16:13 <+sburjan> is the build already finished ?
16:13 <@cjdelisle> yes, it's in staging, same links should do it.
16:13 <+sburjan> ok
16:13 <+sburjan> re-downloading, re-installing, re-testing :)
16:15 <@sdumitriu> tmortagne, vmassol: You recently fixed the rendering so that included documents are rendered using the right syntax
16:15 <vmassol> sdumitriu: yes
16:15 <vmassol> the syntax is saved in the XDOM
16:16 <@sdumitriu> The same problem happens for macros, i.e. invoking a macro defined in a xwiki/2.1 document in a xwiki/2.0 document will try to render the macro content in xwiki/2.0
16:16 <vmassol> (as a MetaDataBlock)
16:16 <@sdumitriu> I'm working on an old 3.1 snapshot, did you fix it already?
16:16 <vmassol> no
16:16 <vmassol> doesn't ring a bell
16:16 <@sdumitriu> Should I report it?
16:16 <+tmortagne> sdumitriu: how do you know this macro is not of the document syntax ?
16:16 <@sdumitriu> Is it easy to fix?
16:16 <+tmortagne> I don't understand exactly your use case
16:17 <@sdumitriu> WDYM how do I know? I'm experiencing the problem
16:17 <+tmortagne> ho do you get this macro which is not in the document syntax ?
16:17 <@sdumitriu> Usecase: refactor the {{activity}} macro so that it uses fewer {{html}} macros
16:17 <@sdumitriu> This means using image:icon: elements, which only work in 2.1
16:18 <@sdumitriu> I changed the Main.Activity macro to use the xwiki/2.1 syntax
16:18 <@sdumitriu> When looking at Main.Activity, the stream looks fine
16:18 <@sdumitriu> When looking at Main.Dashboard, I get the alt text instead of icons
16:18 <+tmortagne> did not understood you were talking about a wiki macro
16:18 <+tmortagne> this as nothing to do what the fix done for include then
16:19 <+tmortagne> since wiki macro are supposed to be executed fully before producing XDOM to include in the document
16:20 <+tmortagne> so you should report it indeed, it's probably a bug somewhere in DefaultWikiMacro
16:20 <@sdumitriu> K
16:20 <+tmortagne> and a very serious one
16:22 <+sburjan> cjdelisle: fix worked :)
16:22 <@cjdelisle> cool
16:23 <jvelociter> has joined #xwiki
16:23 <jvelociter> rephlex
16:24 <vmassol> is that some spam?
16:24 <vmassol> a new drug name?
16:24 <+jvelociter> lol
16:24 <+jvelociter> wrong chat
16:27 <+sburjan> LOL
16:28 <+sburjan> sdumitriu, tmortagne : where can I change t he virtual or domain based XEM's ? I forgot where is the config file
16:29 <+jvelociter> Denis: Hi. I'm trying to find the link you've posted with the git strategy for maintaining your fork but it seems I can't find it in IRC chat archives
16:29 <+jvelociter> would you mind pasting it again for me ?
16:29 <+tmortagne> sburjan: xwiki.cfg
16:29 <+tmortagne> search for "path"
16:30 <+tmortagne> sburjan: http://manager.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki
16:30 <+jvelociter> Denis: wait, I've found it
16:30 <+jvelociter> thanks google :)
16:30 <+jvelociter> http://softec.xwiki.softec.lu/site/DevelopersCorner/GitFastForwardFork?language=en
16:31 <+Denis> jvelociter: that's it :)
16:31 <+Denis> let me know if you have any comments
16:34 <+sburjan> tmortagne: thank you
16:34 <pulasthi1> has joined #xwiki
16:35 <vmassol> has quit
16:36 <+jvelociter> Denis: I will try to put this into practice, and will let you know how it works for me. Right now I don't have enough git experience to have even an opinion about it :)
16:36 <pulasthi1> cjdelisle : hi
16:37 <@cjdelisle> howdy
16:37 <pulasthi1> cjdelisle : im trying to migrate from DN 2.2.2 to 3.0.0
16:38 <pulasthi1> having some problems
16:38 <@cjdelisle> yes, the cassandra plugin is not setup for 3.0
16:38 <@cjdelisle> It's something we can consider doing later on but IMO it's not a priority for now
16:38 <vmassol> has joined #xwiki
16:39 <pulasthi1> the thing is JPA classes are not there in 2.0
16:39 <vmassol> wow my mac just crashed!
16:40 <@cjdelisle> I remember the powerpc imacs at my highschool were horrible, beachball of death, mouse stops moving, etc.
16:41 <pulasthi> has joined #xwiki
16:41 <tmortagne> has quit
16:41 <vmassol> last time it happened was 2 years ago
16:43 <@cjdelisle> I think they got a lot more stable when they went to the x86 stack since they didn't have to support the entire stack themselves.
16:43 <pulasthi> cjdelisle: all the classes in 2.0 are for JDO right 3.0 has a new datanuclues.api.jpa pachakge
16:44 <pulasthi1> has quit
16:44 <@cjdelisle> I see this:
16:44 <@cjdelisle> http://www.datanucleus.org/products/accessplatform_2_1/jpa/jpql.html
16:44 <@cjdelisle> which is 2.1
16:44 <@cjdelisle> and the plugin seems to be running on 2.2.2
16:45 <+sburjan> guys.. I god some hardcore errorson XEM when creating a sub-wiki. The sub-wiki is created, but I get a HUGE stack
16:45 <+sburjan> *got
16:45 <+sburjan> hibernate related
16:47 <pulasthi> but thw org.datanucleus.jpa packge has nothing inside in the datanucleus 2.2.2 jar
16:47 <pulasthi> thw * the
16:47 <+sburjan> http://pastebin.com/eVt4swfU . Note that I let the XEM to create by himself the schema.
16:48 <+sburjan> I'm sure I didn't got these errors on 3.0 and 2.7.1 XEM's
16:50 <@sdumitriu> Seems to be caused by the autowatch feature
16:50 <@sdumitriu> Failed to watch document [sorinello:XWiki.SchedulerJobTemplate] for user [templatexe:XWiki.Admin]
16:50 <+sburjan> I can give you web and ssh access if you need to dig deeper
16:50 <@sdumitriu> It's wrong that the user is considered to be [templatexe:XWiki.Admin]
16:50 <@cjdelisle> pulasthi: did you create a dependency on the datanucleus jpa query module?
16:51 <@sdumitriu> I'm pretty sure you weren't logged in with the templatexe user, right sburjan?
16:51 <+sburjan> I was admin when created the wiki
16:51 <@sdumitriu> Yes, but from the main wiki
16:52 <pulasthi> cjdelisle : didn't quit get what you said
16:52 <+sburjan> yes, logged as Admin, created the templatexe from the Check If Instalation is successful, the created the sorinello subwiki. I was never logged as templatexe
16:53 <@cjdelisle> pulasthi: have a look at this: http://www.datanucleus.org/products/accessplatform/guides/maven2/index.html
16:53 <@cjdelisle> you need to include jpa as a dependency in the pom.xml file
16:55 <+sburjan> sdumitriu, cjdelisle : should I report this and continue the release, or you want to fix this before releasing ?
16:55 <@sdumitriu> Just report it
16:55 <@sdumitriu> It's not critical for 3.1
16:55 <pulasthi> cjdelisle : ahh i did through the IDE that's what brought up the whole 3.0 issue :) . the IDE inserts the latest version it seems
16:55 <abusenius> has joined #xwiki
16:55 <@cjdelisle> I see
16:56 <+sburjan> ok, and more exactly sdumitriu , what should I mention in the issue ?
16:56 <pulasthi> cjdelisle :anyway 3.0 is a little different than 2.0 the class OMFContext has been removed
16:57 <pulasthi> and they has separated jdo and jpa from the core
16:57 <@cjdelisle> yes, that is what I found and at that point I decided it wasn't critical to do the upgrade.
16:57 <@sdumitriu> sburjan: Other than the stacktrace, simply that creating a new wiki results in an exception because of the autowatch feature
16:58 <pulasthi> hmm ok ill add the dependency manually and go back to 2.2.2
16:59 <JunHAN> has joined #xwiki
17:00 <JunHAN> has left #xwiki
17:03 <kwoot> has quit
17:04 <pgmjsd> has joined #xwiki
17:08 <abusenius> has quit
17:14 <xwikibot> has joined #xwiki
17:23 <tmortagne> has joined #xwiki
17:24 <@sdumitriu> tmortagne: Created XWIKI-6723
17:24 <@sdumitriu> The syntax is passed to the constructor
17:25 <@sdumitriu> of the DefaultWikiMacro
17:26 <+tmortagne> sdumitriu: ok thanks, I think I know hat's wrong
17:26 <+tmortagne> since the content of the macro is stored as XDOM the syntax is probably not stored anymore in DefaultWikiMacro
17:26 <+tmortagne> will look at it
17:27 <+tmortagne> so XWIKI-6723 is true only for macro in the wiki macro but not for the macro direct content
17:28 <sburjan> has quit
17:47 <mflorea> has quit
17:49 <Enygma`> has quit
17:49 <evalica> has quit
17:51 <fmancinelli> has joined #xwiki
17:53 <DrLou> has joined #xwiki
17:57 <abusenius> has joined #xwiki
18:06 <+sburjan`> is DynDNS becoming a paid service or did I recieved a scam e-mail ?
18:10 <pulasthi> has quit
18:10 <@cjdelisle> check the headers, it should tell you itself
18:11 <@cjdelisle> also if they are then it should be obvious from the front page of their website
18:11 <+sburjan`> it's them. seems I haven't used their services in 30 days and they warned about my account expiration
18:11 <pulasthi> has joined #xwiki
18:18 <@cjdelisle> are you finished with post-release testing?
18:29 <tmortagne> has quit
18:39 <venkatesh> has joined #xwiki
18:45 <tekzilla> has quit
18:47 <+sburjan`> cjdelisle: didn't even started. That's after the official release
18:48 <@cjdelisle> but then what would we do if you wound a problem?
18:48 <@cjdelisle> *found
18:48 <+sburjan`> fix it in the next release. The post-release is only for validation, mostly for customer projects
18:49 <vmassol> sburjan`: there might not be any need for post release testing anymore
18:49 <vmassol> with the staging strategy
18:49 <+sburjan`> ludovic insisted I test after release too, so we find bugs to release the minor version
18:49 <@cjdelisle> The binaries that are in the staging repo now are going to be copied into the final repo so what you are testing now is exactly the same as what will (if nothing is broken) be released to the wild.
18:50 <vmassol> you can actually kill 2 birds with one stone I think
18:50 <tekzilla> has joined #xwiki
18:50 <vmassol> by doing one test run on the staging artifacts
18:50 <+sburjan`> staging is new for me, didn't had time to adapt to it. Also, if you awnt pre-relase while staging, you'll have to extend staging because 2 days aren't enough
18:50 <@cjdelisle> In fact I have the sha1s of them here and if they don't match then the copy is done over.
18:51 <vmassol> sburjan`: how many days do you need? (that's an important parameter)
18:51 <+sburjan`> if we're gonna use staging method, I'll have to rethink my testing strategy
18:51 <+sburjan`> 3-4 days, depends if I find a blocker that takes time to be seolved
18:51 <vmassol> if you find a blocker it's different since it also needs fixing time
18:52 <@cjdelisle> This is off topic but I think it's a good idea to start rethinking the whole RC process now that we have staging implemented.
18:52 <+sburjan`> like we had last week with those 2 blockers.. that took one day
18:52 <vmassol> cjdelisle: not 100% sure
18:52 <vmassol> it's not going to change the fact that you need to give time for people to test
18:52 <+sburjan`> yes, but I usually find the blocker in those 3-4 days of testing
18:52 <vmassol> and most of our users will only test released versions
18:52 <vmassol> (not staged ones)
18:54 <vmassol> there are 2 different aspects: the best we can test with the dev resources and the tests that can be done by the community at large
18:54 <@cjdelisle> perhaps we could copy the release out of staging and modify the version number to say RC* so that what people are testing is precisely the same as what is released. What always bothered me about RC was that it wasn't the actual compile run that made the final version.
18:54 <vmassol> yes I agree with this
18:54 <vmassol> maven has the notion of promotion
18:54 <vmassol> but that needs to be researched
18:54 <+sburjan`> vmassol: do you think 2-3 days is too much for testing ?
18:54 <vmassol> because again it's not a copy
18:54 <vmassol> you need to change several things
18:54 <vmassol> - the version.properties file
18:55 <vmassol> - all maven poms that get included in META)-INF
18:55 <vmassol> sburjan`: no, it's fine
18:55 <vmassol> (for one person I mean)
18:55 <+sburjan`> vmassol: if no blockers are found 2-3 days is ok, but if we find blockers, that also takes time to fix and confirm the fix, which increases testing time, and also delays the release in most cases
18:56 <vmassol> for a community to test (ie install in their pre prod environment, playground, etc) they usually need more than a month in total
18:56 <vmassol> :)
18:56 <vmassol> sburjan`: that's ok
18:56 <vmassol> not all problems have to be considered blockers
18:56 <vmassol> a blocker is a lbocker
18:56 <+sburjan`> my utopic ideal case is when I'll have something on staging 3 days prior release
18:56 <vmassol> yes we need to incorporate the staging/testing time in our roadmap dates
18:56 <+sburjan`> so I won't test while devs are still commiting
18:56 <vmassol> ie the RM needs ot take that into account
18:57 <vmassol> sburjan`: if you test only staging it won't happen
18:57 <pulasthi1> has joined #xwiki
18:57 <vmassol> if we get our CI build working as the geneal rule
18:57 <+sburjan`> I always download daily the latest trunk, but I'm not in "hunt" mode every day
18:57 <@cjdelisle> indeed, with staging you will never need to test a snapshot prior to the release (announcement)
18:58 <vmassol> then RM should start the release about 3-4 days prior to reelase date
18:58 <vmassol> 1-2 days to make the staging release and 2-3 days for testing
18:58 <vmassol> that's 3-5 days
18:58 <+sburjan`> basically all I'm saying is that me, as a one person who tests, is good to have 2-3 days in which everything is frozen.. so while I test, we are sure devs don't introcude new issues that I won't catch on that release
18:59 <vmassol> since RC is about 2 weeks right now
18:59 <vmassol> actually cjdelisle I agree with you
18:59 <vmassol> RC could become this process
18:59 <vmassol> we could reduce it by 1 week
18:59 <vmassol> (it's now 2 weeks)
18:59 <vmassol> I've always found the stabilization phase to be too long
19:00 <vmassol> so indeed once the laste milestone is released
19:00 <+sburjan`> vmassol: i know that staging with 3-4 days is kinda hard because you can commit a lot in those days ..
19:00 <@cjdelisle> We could rename the file RC but leave everything inside as the final version.
19:00 <vmassol> we could directly enter a staging phase
19:00 <+sburjan`> and it's valuable time taken from the dev team
19:00 <vmassol> sburjan`: the rule would be only commit blocker fixes
19:00 <pulasthi> has quit
19:00 <vmassol> the dev team continues to commit
19:00 <vmassol> but not for the releas
19:00 <vmassol> release
19:00 <vmassol> for the next one
19:00 <vmassol> (ie on master)
19:00 <+sburjan`> we should think this over and have it written somewhere
19:01 <vmassol> obviously
19:01 <vmassol> :)
19:01 <+sburjan`> vmassol: what you are saying is true for RC's because when we reach RC the trunk is already on one version ahead. but it's not the case in Milesttone stages
19:01 <+sburjan`> so I don't know how can you freeze staging for M's
19:01 <vmassol> yes I was only speaking for RCs
19:02 <+sburjan`> but anyway, no one will use M's in production, so it's ok
19:02 <+sburjan`> but in the case of RC's and _especially_ in final versions, we should enforce staging before release
19:02 <@cjdelisle> I branch milestones, it's just that I do it quietly so that people don't stampede to backport their new features ;)
19:03 <vmassol> we can decide later on if we want staging for milestones too but I'm not 100% sure yet about that
19:03 <vmassol> I'm 100% sure we want it for RC/final though
19:03 <+sburjan`> so we are sure no one will introduce a bug in the last day before release and I might not catch it
19:04 <pulasthi1> has left #xwiki
19:04 <@cjdelisle> yes, we have fixed 2 bugs so far, if we were using RC names then we would now be on -rc-3
19:04 <+sburjan`> because the responsability of assuring a decent level of quality is mine :)
19:04 <vmassol> it's all committer's responsbiility
19:04 <vmassol> not just yours sburjan`
19:04 <vmassol> you're mixing your role in XWiki SAS and the xwiki open source project ;)
19:05 <vmassol> but in any case developers must be responsible for the quality of the work they do
19:05 <+sburjan`> well if one of them needs quality, why can't the other have it too :P
19:06 <vmassol> your main role from the XWiki SAS POV is to test stuff that are not tested by the opne source project (or less well tested)
19:06 <vmassol> for ex support for IE6 which is important for cusomter projets but less for the oss project
19:06 <vmassol> testing on oracle, etc
19:06 <vmassol> ie everything that XWiki SAS supports but not specifically the open source project
19:06 <+sburjan`> it is crucial for XWiki SAS to know if they can rely on a version (IE6 support, etc).. and they want to know major bugs on a release _before_ they use it on customer projects. This is the core objective of the post-release testing.
19:07 <@cjdelisle> Remember, the final responsability falls on the release manager and he has the power to revert so there are lots of eyes on the commits that get slipped under the door before release.
19:07 <vmassol> of course it doens't hurt to also help the open soruce project test all the other stuff but then you have a different hat IMO (the open source one) ;)
19:09 <+sburjan`> I've beaten my record last week.. I stopped the release with 2 blockers .. hope I didn't missed a third
19:11 <vmassol> what were the blockers already?
19:12 <+sburjan`> regarding the rename issue and the broken packages (exe and jar)
19:13 <vmassol> btw regarding rename we sitll don't have a functional test for it
19:13 <vmassol> we need one
19:14 <+sburjan`> +1
19:14 <+sburjan`> let's say rename was more blocker for SAS than OSS
19:14 <+sburjan`> but IMO still a critical even for OSS
19:14 <vmassol> go to go, swimming training, bb later
19:20 <fmancinelli> has quit
19:30 <venkatesh> has quit
20:02 <arkub> has quit
20:04 <jvelociter> has quit
20:04 <jvelociter> has joined #xwiki
20:24 <jvelociter_> has joined #xwiki
20:27 <jvelociter> has quit
20:27 <jvelociter_> is now known as <jvelociter>
21:16 <mflorea> has joined #xwiki
21:38 <vmassol> 3 restarts of myxwiki
21:38 <vmassol> every time 100% cpu
21:38 <vmassol> dinner time
21:55 <jvelociter> has quit
21:56 <jvelociter> has joined #xwiki
22:17 <abusenius_> has joined #xwiki
22:17 <abusenius> has quit
22:19 <abusenius_> is now known as <abusenius>
22:22 <sdumitriu> has quit
22:33 <sdumitriu> has joined #xwiki
22:34 <vmassol> has quit
23:17 <mflorea> has quit
23:43 <+sburjan`> sdumitriu: did you get the mail on notifications with the subject "Green technology offer" ?
23:44 <@cjdelisle> I got it, spaaaam
23:44 <+sburjan`> ok, so now out lists are becomming spam :(
23:45 <+sburjan`> like it wasn't alreadye nough
23:45 <@cjdelisle> yea, it's because the smtpds are comfigured incorrectly and they relay mail with invalid headers
23:45 <+sburjan`> yeah, open relay
23:46 <+sburjan`> it's odd that they seem legit.. the from and to fields seem legit
23:46 <tekzilla_> has joined #xwiki
23:46 <+sburjan`> you have to look in the source to see it's spam
23:46 <@cjdelisle> sort of but (hopefully) not relaying to the entire world
23:46 <+sburjan`> this is pure damage.. from slow and crowded internet up to electrical power consumed
23:47 <@cjdelisle> if I ran an smtpd, spammers would talk of it only under their breath <evil grin>
23:47 <+sburjan`> :D
23:49 <@cjdelisle> http://www.symantec.com/connect/articles/slow-down-internet-worms-tarpits
23:49 <@cjdelisle> ``the concept of a TCP session not "letting go" could be really distressing to some TCP stacks and operating systems -it's even possible that they may crash''
23:50 <@sdumitriu> Didn't receive it, gmail has a good filter
23:50 <tekzilla> has quit
00:04 <abusenius> has quit
03:46 <abusenius_> has quit
04:20 <DrLou> has quit
07:51 <vmassol> has joined #xwiki
08:01 <mflorea> has joined #xwiki
08:13 <vmassol> has quit
08:28 <sdumitriu> has joined #xwiki
08:29 <tmortagne> has joined #xwiki
08:37 <vmassol> has joined #xwiki
08:56 <vmassol> agents are stuck
08:56 <vmassol> good morning
08:56 <vmassol> stopping them
08:57 <+tmortagne> vmassol: too many open files
08:57 <+tmortagne> for the trunk one at least
08:57 <vmassol> has alex increased them already?
08:57 <+tmortagne> no idea I asked him but...
08:57 <@sdumitriu> On a3, yes
08:57 <+tmortagne> it's agent2
08:57 <vmassol> yes on a3 but that's a1 & 2
08:58 <vmassol> tmortagne asked on friday
08:58 <vmassol> for a1 & 2
08:58 <vmassol> have we checked which application has the files open?
09:01 <arkub> has joined #xwiki
09:01 <+tmortagne> speaking of which
09:01 <+tmortagne> who wants to be a m... build manager ?
09:02 <sburjan> has joined #xwiki
09:03 <vmassol> 810 opened by java process
09:03 <vmassol> 433 by apache
09:04 <vmassol> tmortagne: btw when you read the web-inf/lib files do we release the handle you have on them? (just to be sure ;))
09:04 <+tmortagne> trying wit no build running
09:04 <vmassol> (with the extension manager I mean)
09:05 <+tmortagne> vmassol: I think yes, and we read this since a long time now, I will check
09:05 <+tmortagne> what agent are you looking at ?
09:05 <+tmortagne> agent2
09:05 <vmassol> yes
09:05 <+tmortagne> stoping all build on it just to be sure
09:06 <vmassol> 1816 open files on agent2
09:06 <+tmortagne> ok stopped
09:06 <+tmortagne> (stopped jenkins itself actually)
09:06 <+tmortagne> to see if there is something wrong on the server
09:06 <vmassol> there's still a java process running on agent2
09:06 <+tmortagne> how many do you have now ?
09:07 <vmassol> could be xwiki
09:07 <+tmortagne> hmm
09:07 <vmassol> 1816
09:07 <vmassol> it's tomcat
09:07 <+tmortagne> actually hudson is still running it seems
09:07 <vmassol> yes
09:08 <+tmortagne> there is a lot of deleted files open
09:08 <+tmortagne> lucene
09:09 <+tmortagne> though that was fixed
09:09 <+tmortagne> looks like we are getting the lucene bug about deleted files
09:10 <vmassol> tmortagne: where do you see that? I only see the files in web-inf/lib
09:10 <vmassol> (for the java process)
09:10 <vmassol> (and the jdk ones)
09:10 <+tmortagne> I get lots of things like
09:10 <+tmortagne> "java 12277 hudsonagent 549r REG 8,2 109787 50711541 /home/hudsonagent/hudson_root/workspace/xwiki-enterprise-tests/xwiki-enterprise-test/xwiki-enterprise-test-ui/target/xwiki-enterprise-jetty-hsqldb-3.2-SNAPSHOT/jetty/work/Jetty_0_0_0_0_8080_xwiki__xwiki__5alevh/lucene/_4.nrm (deleted)
09:10 <+tmortagne> "
09:10 <+tmortagne> with lsof
09:11 <vmassol> sudo lsof | grep lucene | wc -l
09:11 <vmassol> gives me 12 lucene files
09:11 <vmassol> that's not a lot
09:11 <+tmortagne> I have certaininly a lot more than 12
09:11 <+tmortagne> maybee not anymore
09:11 <+tmortagne> recehcking
09:11 <vmassol> sudo lsof | grep WEB-INF | wc -l
09:12 <vmassol> gives 624
09:12 <vmassol> that's a lot
09:12 <+tmortagne> yep I still have a lot
09:12 <vmassol> you're on agent2?
09:12 <vmassol> what command to do you execute?
09:12 <+tmortagne> just execute lsof and look
09:12 <+tmortagne> there is more that 12 for sure
09:13 <vmassol> can you run my command?
09:13 <vmassol> if you just run lsof you'll get thousands of entries
09:13 <+tmortagne> 182
09:13 <+tmortagne> just executed you command
09:13 <+tmortagne> are you sure you are on agent2 ?
09:13 <vmassol> ok so it must be fluctuating which is good
09:13 <vmassol> 10 now
09:13 <vmassol> hmmm
09:13 <+tmortagne> it's not fluctuating for me
09:13 <+tmortagne> I always get the same number
09:13 <vmassol> I did a ssh agent2.myxwiki.org
09:14 <vmassol> ah myxwiki
09:14 <vmassol> what is agent2 on myxwiki?
09:14 <vmassol> hmmm
09:14 <+tmortagne> hudson is agent-2.maven.xwiki.org
09:14 <+tmortagne> s/hudson/jenkins/
09:16 <jvdrean> has joined #xwiki
09:21 <+tmortagne> 1110 files opened total on agent2 it seems
09:21 <+tmortagne> so not enough to beat 2048
09:22 <vmassol> tmortagne: what's ulimit -n on agent-2
09:22 <+tmortagne> hmm
09:22 <+tmortagne> 1024
09:22 <vmassol> so that's why...
09:22 <+tmortagne> but ales just said he restarted it
09:22 <vmassol> ask him to check again maybe? :)
09:23 <vmassol> guys we need someone for this week as Build Manager: http://dev.xwiki.org/xwiki/bin/view/Community/BuildManagerRoster
09:23 <+tmortagne> actually he did not restarted it since I would not have xwiki otherwise
09:23 <vmassol> if nobody volunteers we'll pick a committer at random :)
09:24 <vmassol> role is described at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBuildManagerRole
09:28 <+tmortagne> I see 888 files opened on agent2 which seems a lot to build commons
09:28 <+tmortagne> agent3 sorry
09:29 <+tmortagne> 314 jar files
09:29 <Enygma`> has joined #xwiki
09:31 <vmassol> tmortagne: when XE executes that creates a lot more open files I think
09:32 <+tmortagne> sure but it's still a lot IMO
09:32 <evalica> has joined #xwiki
09:32 <+tmortagne> maybe jenkins is expensive too
09:32 <+tmortagne> in any case 1024 is certainly not enough seeing that
09:33 <+tmortagne> but what I don't understand is why now ?
09:33 <vmassol> it's not just now, been happening for some time already
09:34 <vmassol> maybe we were close to the limit and we added some jars to web-inf/lib for ex
09:34 <vmassol> we also upgraded some libraries
09:34 <vmassol> in 3.1
09:34 <+tmortagne> it happen all the time theses days and it's rare enough before for me to not remember any of them
09:34 <vmassol> also we moved to jdk6
09:34 <vmassol> the jdk opens a lot of files
09:34 <vmassol> too
09:34 <+tmortagne> yea
09:34 <+tmortagne> anyway hope it's not a leak
09:35 <+tmortagne> (checked EM btw it's properly closing the stream)
09:35 <vmassol> I'd like to know who hold a lock on the web-inf/lib jars
09:35 <vmassol> is it just the jdk
09:35 <vmassol> or is our app
09:35 <vmassol> s/is/is it/
09:36 <+tmortagne> probably the jdk maybe jetty too
09:47 <+mflorea> tmortagne: would you agree that is relatively easy to write a transformation that transforms WordBlock to a link if the word matches an existing tag?
09:47 <@sdumitriu> Yes
09:47 <+tmortagne> mflorea: yes it should
09:48 <+mflorea> ok, thanks, I suppose we don't have something like this already?
09:48 <@sdumitriu> But I'm not sure that's what you need, mflorea
09:48 <vmassol> mflorea: we do
09:48 <+tmortagne> write a transformation in general is very easy, then there is the transformation itself
09:48 <@sdumitriu> Yes, the CamelCase
09:48 <vmassol> I have coded wikiwords transofrmation for ex
09:48 <+mflorea> vmassol: that's different I think
09:48 <vmassol> sure
09:48 <vmassol> but very close
09:48 <+mflorea> I'm looking for links to tags
09:49 <+mflorea> yes, I agree
09:49 <vmassol> for tags you'll need to
09:49 <+tmortagne> yep it's more or less the same logic
09:49 <vmassol> cache the tags list
09:49 <vmassol> write a listener to intercept tag operation to refresh your cache
09:49 <+mflorea> indeed
09:58 <@sdumitriu> tmortagne: Remote observation test failing: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-observation-remote/277/testReport/org.xwiki.observation.remote/TCPROMTest/testSerializableEvent/
09:58 <@sdumitriu> Can you look into it?
09:58 <+tmortagne> sdumitriu: yes I know
09:58 <+tmortagne> I tested lots of think looks like I will have to come back to custom files on for ci
09:58 <+tmortagne> s/think/things/
10:13 <vmassol> tmortagne: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-observation-remote/278/ :)
10:14 <+tmortagne> vmassol: that's weird this build does not contains my last modification
10:14 <+tmortagne> should have failed like the one before it
10:14 <@sdumitriu> Indeed
10:16 <+tmortagne> or maybe it's just failing on some agent(s) since I still don't understand why it's failing
10:16 <+tmortagne> so if true it mean it's failing on agent3 and not on agent1
10:17 <+tmortagne> tying next build to agent3
10:20 <+tmortagne> at least I know some configuration works on agent3 since 3.1 build well oon it
10:20 <+tmortagne> s/oon/on/
10:20 <+tmortagne> lets see this as a good things, force me to find some configuration that will build well on more environment, always better for tests ;)
10:24 <+tmortagne> cool looks like I found it this time
10:24 <+tmortagne> so it's working with localhost and not with 127.0.0.1
10:25 <+tmortagne> jgroups is pretty sensible
10:34 <vmassol> sensitive not sensible ;)
10:34 <vmassol> (tmortagne)
10:34 <vmassol> sensible means almost the opposite :)
10:36 <+tmortagne> lets say ticklish then :)
10:44 <vmassol> ok ulimit should be ok now on all agents
10:53 <cjdelisle> has joined #xwiki
10:58 <Denis> has joined #xwiki
11:16 <vmassol> btw myxwiki.org has restarted 2 or 3 times over the weekend….
11:16 <vmassol> not sure why yet
11:17 <vmassol> btw this is strange:
11:17 <vmassol> com.xpn.xwiki.XWikiException: Error number 3202 in 3: Exception while reading document name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [CDATA[ */
11:17 <vmassol> document.observe('dom], type = [WIKI], parent = [null]]]
11:17 <vmassol> Wrapped Exception: Error number 3301 in 3: Exception while switching to database CDATA[ */
11:17 <vmassol> document.observe('dom
11:17 <vmassol> Wrapped Exception: Incorrect database name 'CDATA[ */
11:17 <vmassol> document.observe('dom'
11:17 <vmassol> at com.xpn.xwiki.store.XWikiHibernateStore.loadXWikiDoc(XWikiHibernateStore.java:811) ~[xwiki-platform-oldcore-3.1-20110602.173052-162.jar:na]
11:17 <vmassol> should be ok
11:18 <vmassol> seems ot be coming from the rendering of a page
11:18 <vmassol> in xwiki 1.0 syntax
11:18 <vmassol> at com.xpn.xwiki.render.XWikiRadeoxRenderEngine.appendCreateLink(XWikiRadeoxRenderEngine.java:312) [xwiki-platform-oldcore-3.1-20110602.173052-162.jar:na]
11:18 <vmassol> at com.xpn.xwiki.render.filter.XWikiLinkFilter.handleMatch(XWikiLinkFilter.java:211) [xwiki-platform-oldcore-3.1-20110602.173052-162.jar:na]
11:20 <vmassol> hmm still
11:21 <vmassol> it's reading XWiki.XWikiPreferences
11:27 <fmancinelli> has joined #xwiki
11:33 <+tmortagne> vmassol: that's because xwiki/1.0 syntax is matching a lots of things as links as long as it find a [something]
11:34 <fmancinelli> has quit
11:34 <vmassol> tmortagne: indeed you must be right
11:34 <+tmortagne> it always produce bad things like that
11:34 <@cjdelisle> Hi all, I'd like to see if I can release just enterprise into nexus instead of dropping the whole repo and rereleasing everything.
11:35 <vmassol> it must be evaluating a text area on XWikiPreferences
11:35 <vmassol> cjdelisle: you're back cool! :)
11:42 <vmassol> node1 crashed again
11:46 <vmassol> there are quite a few threads blocked on
11:46 <vmassol> Â java.lang.Thread.State: BLOCKED (on object monitor)
11:46 <vmassol> at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
11:46 <vmassol> - waiting to lock <0x00000000ce5282b8> (a org.apache.catalina.loader.StandardClassLoader)
11:46 <vmassol> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
11:46 <vmassol> about 6-7
11:47 <vmassol> I see a lot of RUNNABLE threads though so I don't understand why it wasn't responding
11:48 <vmassol> hmmm
11:48 <vmassol> 27106 tomcat    20   0 1662m 1.2g  18m S   99 61.1 149:58.44 java Â
11:48 <vmassol> that's 99% cpu?
11:49 <vmassol> 27106 tomcat    20   0 1662m 1.2g  18m S  100 61.1 149:58.94 java      Â
11:49 <vmassol> ok so tomcat was eating all cpu apparently
12:08 <DrLou> has joined #xwiki
12:22 <abusenius_> has joined #xwiki
12:30 <abusenius_> is now known as <abusenius>
12:42 <abusenius> has quit
12:52 <mflorea> has quit
12:58 <@cjdelisle> sburjan: I just sent mail to the list about the re-release (into staging) of enterprise, some testing on that would be excellent.
13:10 <+sburjan> cjdelisle: I'll re-test the packages
13:33 <kwoot> has joined #xwiki
13:33 <kwoot> hello verybod. If I want to tweak pdf export to include a company logo, what should be the syntax to put in pdfheader.vm? would be soooo nice to know.
13:34 <@sdumitriu> HTML
13:39 <mflorea> has joined #xwiki
13:40 <kwoot> hello mflorea. Do you know the answer to this one? If I want to tweak pdf export to include a company logo, what should be the syntax to put in pdfheader.vm? would be soooo nice to know.
13:52 <@sdumitriu> kwoot: HTML
13:53 <@sdumitriu> HTML + Velocity
13:55 <+sburjan> cjdelisle: packages work. just tested. I'm replying also on the list
13:56 <+mflorea> kwoot: you can start with:
13:56 <+mflorea> <img src="$xwiki.getSkinFile('logo.png')" alt="logo" />
13:59 <kwoot> cool!
14:00 <@cjdelisle> awesome, I also released manager, I'm not sure if you traditionally do any testing on that
14:02 <abusenius> has joined #xwiki
14:09 <kwoot> mflorea: this works nice but show only a logo in the content pages, after the title and after the toc page. Is there a way to get this logo on every page?
14:28 <+sburjan> cjdelisle: usually I don't get the chance only after the release. If you wait a few hours I could do that. Tomcat + mysql + war. I am unable to reply on the list due to technical issues
14:30 <@cjdelisle> I think a final release can wait a few hours.
14:34 <+mflorea> kwoot: have you tried putting it on pdfcover.vm and pdftoc.vm also?
14:34 <+mflorea> note that I'm not an expert at this :)
14:35 <kwoot> i'?l give ut a try, Just thought maybe there is a global setting somewhere. Will hack the pdfcover and pdftoc instead. thanks!
14:38 <+sburjan> cjdelisle: just found that XEM Test machine doesn't have network access.. investigating
14:42 <+sburjan> cjdelisle: give me the staging links to the XEM builds
14:42 <+sburjan> zip + war
14:42 <@cjdelisle> they should be the same as the ones from the last email from thursday
14:43 <+sburjan> ok
14:44 <+sburjan> cjdelisle: something is not right or the name of the packages are changed
14:45 <+sburjan> I am expecting some file called: xwiki-enterprise-manager-mysql-3.1.zip, but I find a xwiki-manager-jetty-mysql-3.1.zip
14:46 <+sburjan> what am I missing ?
14:46 <@cjdelisle> that has changed as of 3.1
14:47 <+sburjan> ok.
14:47 <@sdumitriu> The new name is normal
14:48 <mflorea> has quit
14:48 <+sburjan> so basically now we have a package that bundles jetty in it ?
14:48 <mflorea> has joined #xwiki
14:50 <@sdumitriu> Ah, no
14:50 <@sdumitriu> Or yes?
14:50 <@sdumitriu> let me check
14:51 <@sdumitriu> Yes, we always had a jetty package
14:51 <@sdumitriu> xwiki-enterprise-manager-mysql-2.7.2.zip included jetty as well
14:52 <@sdumitriu> It doesn't mention -jetty because it's the only type of container distributed with XEM
14:52 <@sdumitriu> XE also has glassfish
14:54 <+sburjan> sdumitriu: yes, I got confused because it didn't had "jetty" in name until now :)
14:54 <+sburjan> also, didn't know we have a glassfish bundle too :)
14:56 <+tmortagne> it's based on a now old beta version of glassfish 3 if I remember well
15:00 <DrLou> has quit
15:07 <+sburjan> cjdelisle: managed to start XEM, I get a XWiki Enterprise 3.1.${buildNumber} in the footer
15:07 <+sburjan> so I guess something is not 100% right
15:07 <@sdumitriu> That's wrong
15:07 <@sdumitriu> The buildnumber should be removed
15:08 <@sdumitriu> Duplicated configs are baaaad...
15:12 <+tmortagne> version.properties file should be simply removed from XE since it's exactly the same version since 2.0
15:12 <+tmortagne> XEM
15:12 <+tmortagne> from XEM
15:13 <+tmortagne> taking care of it
15:14 <+tmortagne> *XEM-191
15:14 <+tmortagne> XEM-191
15:16 <@sdumitriu> Are you sure it's the same?
15:17 <+tmortagne> yes I'm sure, XEM is always based on the same XE version
15:17 <+tmortagne> and always released with it anyway
15:17 <@sdumitriu> Shouldn't it be XWiki Enterprise *Manager* 3.1 instead of XWiki Enterprise 3.1?
15:17 <+tmortagne> that has nothing to do with this file
15:18 <abusenius> has quit
15:18 <+tmortagne> this file contains a version not a name
15:19 <+tmortagne> the name part is in XWikiPreference if i remember well
15:20 <@sdumitriu> Right
15:22 <+tmortagne> cjdelisle, sburjan: fixed
15:24 <@sdumitriu> re-re-release?
15:25 <@cjdelisle> heh you saw my note taking the agent offline?
15:25 <@sdumitriu> Nope :)
15:25 <@cjdelisle> "Disconnected by CalebJamesDeLisle : re-re-releasing manager due to XEM-191"
15:26 <@sdumitriu> I guess only manager needs to be released this time
15:26 <@sdumitriu> enterprise is OK
15:26 <+tmortagne> cjdelisle: wait a bit, i'm rechecking something
15:27 <+tmortagne> cjdelisle: it's ok
15:28 <+tmortagne> (was checking if XEM web build was excluding version.properties file before putting its own)
15:40 <@cjdelisle> Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project xwiki-manager-web: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: basedir /home/hudsonagent/releases/xwiki-trunks/xwiki-manager/target/checkout/xwiki-manager-web/src/main/webInfResources does not exist
15:41 <@cjdelisle> I'm going to go get something to eat
15:42 <@sdumitriu> sburjan: I finished XWIKI-6504: Convert Panels application into syntax 2.0
15:42 <@sdumitriu> Can you check the next XE build to check it all works fine? Panels and panel wizard
15:47 <+tmortagne> cjdelisle: thanks weird, I'm checking
15:49 <+tmortagne> cjdelisle: should be ok now
16:01 <@cjdelisle> sburjan: released again...
16:10 <+sburjan> sdumitriu: of course
16:12 <+sburjan> ok cjdelisle ,so I'll have t o wait and re-install the XEM, right ? :)
16:13 <@sdumitriu> Why wait?
16:13 <@sdumitriu> Test now
16:13 <@sdumitriu> From the staging repo
16:13 <+sburjan> is the build already finished ?
16:13 <@cjdelisle> yes, it's in staging, same links should do it.
16:13 <+sburjan> ok
16:13 <+sburjan> re-downloading, re-installing, re-testing :)
16:15 <@sdumitriu> tmortagne, vmassol: You recently fixed the rendering so that included documents are rendered using the right syntax
16:15 <vmassol> sdumitriu: yes
16:15 <vmassol> the syntax is saved in the XDOM
16:16 <@sdumitriu> The same problem happens for macros, i.e. invoking a macro defined in a xwiki/2.1 document in a xwiki/2.0 document will try to render the macro content in xwiki/2.0
16:16 <vmassol> (as a MetaDataBlock)
16:16 <@sdumitriu> I'm working on an old 3.1 snapshot, did you fix it already?
16:16 <vmassol> no
16:16 <vmassol> doesn't ring a bell
16:16 <@sdumitriu> Should I report it?
16:16 <+tmortagne> sdumitriu: how do you know this macro is not of the document syntax ?
16:16 <@sdumitriu> Is it easy to fix?
16:16 <+tmortagne> I don't understand exactly your use case
16:17 <@sdumitriu> WDYM how do I know? I'm experiencing the problem
16:17 <+tmortagne> ho do you get this macro which is not in the document syntax ?
16:17 <@sdumitriu> Usecase: refactor the {{activity}} macro so that it uses fewer {{html}} macros
16:17 <@sdumitriu> This means using image:icon: elements, which only work in 2.1
16:18 <@sdumitriu> I changed the Main.Activity macro to use the xwiki/2.1 syntax
16:18 <@sdumitriu> When looking at Main.Activity, the stream looks fine
16:18 <@sdumitriu> When looking at Main.Dashboard, I get the alt text instead of icons
16:18 <+tmortagne> did not understood you were talking about a wiki macro
16:18 <+tmortagne> this as nothing to do what the fix done for include then
16:19 <+tmortagne> since wiki macro are supposed to be executed fully before producing XDOM to include in the document
16:20 <+tmortagne> so you should report it indeed, it's probably a bug somewhere in DefaultWikiMacro
16:20 <@sdumitriu> K
16:20 <+tmortagne> and a very serious one
16:22 <+sburjan> cjdelisle: fix worked :)
16:22 <@cjdelisle> cool
16:23 <jvelociter> has joined #xwiki
16:23 <jvelociter> rephlex
16:24 <vmassol> is that some spam?
16:24 <vmassol> a new drug name?
16:24 <+jvelociter> lol
16:24 <+jvelociter> wrong chat
16:27 <+sburjan> LOL
16:28 <+sburjan> sdumitriu, tmortagne : where can I change t he virtual or domain based XEM's ? I forgot where is the config file
16:29 <+jvelociter> Denis: Hi. I'm trying to find the link you've posted with the git strategy for maintaining your fork but it seems I can't find it in IRC chat archives
16:29 <+jvelociter> would you mind pasting it again for me ?
16:29 <+tmortagne> sburjan: xwiki.cfg
16:29 <+tmortagne> search for "path"
16:30 <+tmortagne> sburjan: http://manager.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki
16:30 <+jvelociter> Denis: wait, I've found it
16:30 <+jvelociter> thanks google :)
16:30 <+jvelociter> http://softec.xwiki.softec.lu/site/DevelopersCorner/GitFastForwardFork?language=en
16:31 <+Denis> jvelociter: that's it :)
16:31 <+Denis> let me know if you have any comments
16:34 <+sburjan> tmortagne: thank you
16:34 <pulasthi1> has joined #xwiki
16:35 <vmassol> has quit
16:36 <+jvelociter> Denis: I will try to put this into practice, and will let you know how it works for me. Right now I don't have enough git experience to have even an opinion about it :)
16:36 <pulasthi1> cjdelisle : hi
16:37 <@cjdelisle> howdy
16:37 <pulasthi1> cjdelisle : im trying to migrate from DN 2.2.2 to 3.0.0
16:38 <pulasthi1> having some problems
16:38 <@cjdelisle> yes, the cassandra plugin is not setup for 3.0
16:38 <@cjdelisle> It's something we can consider doing later on but IMO it's not a priority for now
16:38 <vmassol> has joined #xwiki
16:39 <pulasthi1> the thing is JPA classes are not there in 2.0
16:39 <vmassol> wow my mac just crashed!
16:40 <@cjdelisle> I remember the powerpc imacs at my highschool were horrible, beachball of death, mouse stops moving, etc.
16:41 <pulasthi> has joined #xwiki
16:41 <tmortagne> has quit
16:41 <vmassol> last time it happened was 2 years ago
16:43 <@cjdelisle> I think they got a lot more stable when they went to the x86 stack since they didn't have to support the entire stack themselves.
16:43 <pulasthi> cjdelisle: all the classes in 2.0 are for JDO right 3.0 has a new datanuclues.api.jpa pachakge
16:44 <pulasthi1> has quit
16:44 <@cjdelisle> I see this:
16:44 <@cjdelisle> http://www.datanucleus.org/products/accessplatform_2_1/jpa/jpql.html
16:44 <@cjdelisle> which is 2.1
16:44 <@cjdelisle> and the plugin seems to be running on 2.2.2
16:45 <+sburjan> guys.. I god some hardcore errorson XEM when creating a sub-wiki. The sub-wiki is created, but I get a HUGE stack
16:45 <+sburjan> *got
16:45 <+sburjan> hibernate related
16:47 <pulasthi> but thw org.datanucleus.jpa packge has nothing inside in the datanucleus 2.2.2 jar
16:47 <pulasthi> thw * the
16:47 <+sburjan> http://pastebin.com/eVt4swfU . Note that I let the XEM to create by himself the schema.
16:48 <+sburjan> I'm sure I didn't got these errors on 3.0 and 2.7.1 XEM's
16:50 <@sdumitriu> Seems to be caused by the autowatch feature
16:50 <@sdumitriu> Failed to watch document [sorinello:XWiki.SchedulerJobTemplate] for user [templatexe:XWiki.Admin]
16:50 <+sburjan> I can give you web and ssh access if you need to dig deeper
16:50 <@sdumitriu> It's wrong that the user is considered to be [templatexe:XWiki.Admin]
16:50 <@cjdelisle> pulasthi: did you create a dependency on the datanucleus jpa query module?
16:51 <@sdumitriu> I'm pretty sure you weren't logged in with the templatexe user, right sburjan?
16:51 <+sburjan> I was admin when created the wiki
16:51 <@sdumitriu> Yes, but from the main wiki
16:52 <pulasthi> cjdelisle : didn't quit get what you said
16:52 <+sburjan> yes, logged as Admin, created the templatexe from the Check If Instalation is successful, the created the sorinello subwiki. I was never logged as templatexe
16:53 <@cjdelisle> pulasthi: have a look at this: http://www.datanucleus.org/products/accessplatform/guides/maven2/index.html
16:53 <@cjdelisle> you need to include jpa as a dependency in the pom.xml file
16:55 <+sburjan> sdumitriu, cjdelisle : should I report this and continue the release, or you want to fix this before releasing ?
16:55 <@sdumitriu> Just report it
16:55 <@sdumitriu> It's not critical for 3.1
16:55 <pulasthi> cjdelisle : ahh i did through the IDE that's what brought up the whole 3.0 issue :) . the IDE inserts the latest version it seems
16:55 <abusenius> has joined #xwiki
16:55 <@cjdelisle> I see
16:56 <+sburjan> ok, and more exactly sdumitriu , what should I mention in the issue ?
16:56 <pulasthi> cjdelisle :anyway 3.0 is a little different than 2.0 the class OMFContext has been removed
16:57 <pulasthi> and they has separated jdo and jpa from the core
16:57 <@cjdelisle> yes, that is what I found and at that point I decided it wasn't critical to do the upgrade.
16:57 <@sdumitriu> sburjan: Other than the stacktrace, simply that creating a new wiki results in an exception because of the autowatch feature
16:58 <pulasthi> hmm ok ill add the dependency manually and go back to 2.2.2
16:59 <JunHAN> has joined #xwiki
17:00 <JunHAN> has left #xwiki
17:03 <kwoot> has quit
17:04 <pgmjsd> has joined #xwiki
17:08 <abusenius> has quit
17:14 <xwikibot> has joined #xwiki
17:23 <tmortagne> has joined #xwiki
17:24 <@sdumitriu> tmortagne: Created XWIKI-6723
17:24 <@sdumitriu> The syntax is passed to the constructor
17:25 <@sdumitriu> of the DefaultWikiMacro
17:26 <+tmortagne> sdumitriu: ok thanks, I think I know hat's wrong
17:26 <+tmortagne> since the content of the macro is stored as XDOM the syntax is probably not stored anymore in DefaultWikiMacro
17:26 <+tmortagne> will look at it
17:27 <+tmortagne> so XWIKI-6723 is true only for macro in the wiki macro but not for the macro direct content
17:28 <sburjan> has quit
17:47 <mflorea> has quit
17:49 <Enygma`> has quit
17:49 <evalica> has quit
17:51 <fmancinelli> has joined #xwiki
17:53 <DrLou> has joined #xwiki
17:57 <abusenius> has joined #xwiki
18:06 <+sburjan`> is DynDNS becoming a paid service or did I recieved a scam e-mail ?
18:10 <pulasthi> has quit
18:10 <@cjdelisle> check the headers, it should tell you itself
18:11 <@cjdelisle> also if they are then it should be obvious from the front page of their website
18:11 <+sburjan`> it's them. seems I haven't used their services in 30 days and they warned about my account expiration
18:11 <pulasthi> has joined #xwiki
18:18 <@cjdelisle> are you finished with post-release testing?
18:29 <tmortagne> has quit
18:39 <venkatesh> has joined #xwiki
18:45 <tekzilla> has quit
18:47 <+sburjan`> cjdelisle: didn't even started. That's after the official release
18:48 <@cjdelisle> but then what would we do if you wound a problem?
18:48 <@cjdelisle> *found
18:48 <+sburjan`> fix it in the next release. The post-release is only for validation, mostly for customer projects
18:49 <vmassol> sburjan`: there might not be any need for post release testing anymore
18:49 <vmassol> with the staging strategy
18:49 <+sburjan`> ludovic insisted I test after release too, so we find bugs to release the minor version
18:49 <@cjdelisle> The binaries that are in the staging repo now are going to be copied into the final repo so what you are testing now is exactly the same as what will (if nothing is broken) be released to the wild.
18:50 <vmassol> you can actually kill 2 birds with one stone I think
18:50 <tekzilla> has joined #xwiki
18:50 <vmassol> by doing one test run on the staging artifacts
18:50 <+sburjan`> staging is new for me, didn't had time to adapt to it. Also, if you awnt pre-relase while staging, you'll have to extend staging because 2 days aren't enough
18:50 <@cjdelisle> In fact I have the sha1s of them here and if they don't match then the copy is done over.
18:51 <vmassol> sburjan`: how many days do you need? (that's an important parameter)
18:51 <+sburjan`> if we're gonna use staging method, I'll have to rethink my testing strategy
18:51 <+sburjan`> 3-4 days, depends if I find a blocker that takes time to be seolved
18:51 <vmassol> if you find a blocker it's different since it also needs fixing time
18:52 <@cjdelisle> This is off topic but I think it's a good idea to start rethinking the whole RC process now that we have staging implemented.
18:52 <+sburjan`> like we had last week with those 2 blockers.. that took one day
18:52 <vmassol> cjdelisle: not 100% sure
18:52 <vmassol> it's not going to change the fact that you need to give time for people to test
18:52 <+sburjan`> yes, but I usually find the blocker in those 3-4 days of testing
18:52 <vmassol> and most of our users will only test released versions
18:52 <vmassol> (not staged ones)
18:54 <vmassol> there are 2 different aspects: the best we can test with the dev resources and the tests that can be done by the community at large
18:54 <@cjdelisle> perhaps we could copy the release out of staging and modify the version number to say RC* so that what people are testing is precisely the same as what is released. What always bothered me about RC was that it wasn't the actual compile run that made the final version.
18:54 <vmassol> yes I agree with this
18:54 <vmassol> maven has the notion of promotion
18:54 <vmassol> but that needs to be researched
18:54 <+sburjan`> vmassol: do you think 2-3 days is too much for testing ?
18:54 <vmassol> because again it's not a copy
18:54 <vmassol> you need to change several things
18:54 <vmassol> - the version.properties file
18:55 <vmassol> - all maven poms that get included in META)-INF
18:55 <vmassol> sburjan`: no, it's fine
18:55 <vmassol> (for one person I mean)
18:55 <+sburjan`> vmassol: if no blockers are found 2-3 days is ok, but if we find blockers, that also takes time to fix and confirm the fix, which increases testing time, and also delays the release in most cases
18:56 <vmassol> for a community to test (ie install in their pre prod environment, playground, etc) they usually need more than a month in total
18:56 <vmassol> :)
18:56 <vmassol> sburjan`: that's ok
18:56 <vmassol> not all problems have to be considered blockers
18:56 <vmassol> a blocker is a lbocker
18:56 <+sburjan`> my utopic ideal case is when I'll have something on staging 3 days prior release
18:56 <vmassol> yes we need to incorporate the staging/testing time in our roadmap dates
18:56 <+sburjan`> so I won't test while devs are still commiting
18:56 <vmassol> ie the RM needs ot take that into account
18:57 <vmassol> sburjan`: if you test only staging it won't happen
18:57 <pulasthi1> has joined #xwiki
18:57 <vmassol> if we get our CI build working as the geneal rule
18:57 <+sburjan`> I always download daily the latest trunk, but I'm not in "hunt" mode every day
18:57 <@cjdelisle> indeed, with staging you will never need to test a snapshot prior to the release (announcement)
18:58 <vmassol> then RM should start the release about 3-4 days prior to reelase date
18:58 <vmassol> 1-2 days to make the staging release and 2-3 days for testing
18:58 <vmassol> that's 3-5 days
18:58 <+sburjan`> basically all I'm saying is that me, as a one person who tests, is good to have 2-3 days in which everything is frozen.. so while I test, we are sure devs don't introcude new issues that I won't catch on that release
18:59 <vmassol> since RC is about 2 weeks right now
18:59 <vmassol> actually cjdelisle I agree with you
18:59 <vmassol> RC could become this process
18:59 <vmassol> we could reduce it by 1 week
18:59 <vmassol> (it's now 2 weeks)
18:59 <vmassol> I've always found the stabilization phase to be too long
19:00 <vmassol> so indeed once the laste milestone is released
19:00 <+sburjan`> vmassol: i know that staging with 3-4 days is kinda hard because you can commit a lot in those days ..
19:00 <@cjdelisle> We could rename the file RC but leave everything inside as the final version.
19:00 <vmassol> we could directly enter a staging phase
19:00 <+sburjan`> and it's valuable time taken from the dev team
19:00 <vmassol> sburjan`: the rule would be only commit blocker fixes
19:00 <pulasthi> has quit
19:00 <vmassol> the dev team continues to commit
19:00 <vmassol> but not for the releas
19:00 <vmassol> release
19:00 <vmassol> for the next one
19:00 <vmassol> (ie on master)
19:00 <+sburjan`> we should think this over and have it written somewhere
19:01 <vmassol> obviously
19:01 <vmassol> :)
19:01 <+sburjan`> vmassol: what you are saying is true for RC's because when we reach RC the trunk is already on one version ahead. but it's not the case in Milesttone stages
19:01 <+sburjan`> so I don't know how can you freeze staging for M's
19:01 <vmassol> yes I was only speaking for RCs
19:02 <+sburjan`> but anyway, no one will use M's in production, so it's ok
19:02 <+sburjan`> but in the case of RC's and _especially_ in final versions, we should enforce staging before release
19:02 <@cjdelisle> I branch milestones, it's just that I do it quietly so that people don't stampede to backport their new features ;)
19:03 <vmassol> we can decide later on if we want staging for milestones too but I'm not 100% sure yet about that
19:03 <vmassol> I'm 100% sure we want it for RC/final though
19:03 <+sburjan`> so we are sure no one will introduce a bug in the last day before release and I might not catch it
19:04 <pulasthi1> has left #xwiki
19:04 <@cjdelisle> yes, we have fixed 2 bugs so far, if we were using RC names then we would now be on -rc-3
19:04 <+sburjan`> because the responsability of assuring a decent level of quality is mine :)
19:04 <vmassol> it's all committer's responsbiility
19:04 <vmassol> not just yours sburjan`
19:04 <vmassol> you're mixing your role in XWiki SAS and the xwiki open source project ;)
19:05 <vmassol> but in any case developers must be responsible for the quality of the work they do
19:05 <+sburjan`> well if one of them needs quality, why can't the other have it too :P
19:06 <vmassol> your main role from the XWiki SAS POV is to test stuff that are not tested by the opne source project (or less well tested)
19:06 <vmassol> for ex support for IE6 which is important for cusomter projets but less for the oss project
19:06 <vmassol> testing on oracle, etc
19:06 <vmassol> ie everything that XWiki SAS supports but not specifically the open source project
19:06 <+sburjan`> it is crucial for XWiki SAS to know if they can rely on a version (IE6 support, etc).. and they want to know major bugs on a release _before_ they use it on customer projects. This is the core objective of the post-release testing.
19:07 <@cjdelisle> Remember, the final responsability falls on the release manager and he has the power to revert so there are lots of eyes on the commits that get slipped under the door before release.
19:07 <vmassol> of course it doens't hurt to also help the open soruce project test all the other stuff but then you have a different hat IMO (the open source one) ;)
19:09 <+sburjan`> I've beaten my record last week.. I stopped the release with 2 blockers .. hope I didn't missed a third
19:11 <vmassol> what were the blockers already?
19:12 <+sburjan`> regarding the rename issue and the broken packages (exe and jar)
19:13 <vmassol> btw regarding rename we sitll don't have a functional test for it
19:13 <vmassol> we need one
19:14 <+sburjan`> +1
19:14 <+sburjan`> let's say rename was more blocker for SAS than OSS
19:14 <+sburjan`> but IMO still a critical even for OSS
19:14 <vmassol> go to go, swimming training, bb later
19:20 <fmancinelli> has quit
19:30 <venkatesh> has quit
20:02 <arkub> has quit
20:04 <jvelociter> has quit
20:04 <jvelociter> has joined #xwiki
20:24 <jvelociter_> has joined #xwiki
20:27 <jvelociter> has quit
20:27 <jvelociter_> is now known as <jvelociter>
21:16 <mflorea> has joined #xwiki
21:38 <vmassol> 3 restarts of myxwiki
21:38 <vmassol> every time 100% cpu
21:38 <vmassol> dinner time
21:55 <jvelociter> has quit
21:56 <jvelociter> has joined #xwiki
22:17 <abusenius_> has joined #xwiki
22:17 <abusenius> has quit
22:19 <abusenius_> is now known as <abusenius>
22:22 <sdumitriu> has quit
22:33 <sdumitriu> has joined #xwiki
22:34 <vmassol> has quit
23:17 <mflorea> has quit
23:43 <+sburjan`> sdumitriu: did you get the mail on notifications with the subject "Green technology offer" ?
23:44 <@cjdelisle> I got it, spaaaam
23:44 <+sburjan`> ok, so now out lists are becomming spam :(
23:45 <+sburjan`> like it wasn't alreadye nough
23:45 <@cjdelisle> yea, it's because the smtpds are comfigured incorrectly and they relay mail with invalid headers
23:45 <+sburjan`> yeah, open relay
23:46 <+sburjan`> it's odd that they seem legit.. the from and to fields seem legit
23:46 <tekzilla_> has joined #xwiki
23:46 <+sburjan`> you have to look in the source to see it's spam
23:46 <@cjdelisle> sort of but (hopefully) not relaying to the entire world
23:46 <+sburjan`> this is pure damage.. from slow and crowded internet up to electrical power consumed
23:47 <@cjdelisle> if I ran an smtpd, spammers would talk of it only under their breath <evil grin>
23:47 <+sburjan`> :D
23:49 <@cjdelisle> http://www.symantec.com/connect/articles/slow-down-internet-worms-tarpits
23:49 <@cjdelisle> ``the concept of a TCP session not "letting go" could be really distressing to some TCP stacks and operating systems -it's even possible that they may crash''
23:50 <@sdumitriu> Didn't receive it, gmail has a good filter
23:50 <tekzilla> has quit
