[10:06] so lets get started :) [10:06] hehe, seems gail is not online right now [10:06] I'm here [10:07] there ya go :) [10:07] so 3.6 [10:07] we need to start planning 3.6 [10:07] one item that was not on the roadmap that we need to discuss is specj [10:08] specj? [10:08] red hat is trying to run specj [10:08] hardy_: a performance test backed up by a standard body [10:09] it (rh/jboss) gets beaten down continuously for not publishing specj numbers [10:09] part of it is jpa [10:09] we already spent some time supporting some specj specific use cases [10:09] there is one more [10:09] and its a big one [10:10] but a worthwhile one on many level;s [10:10] the exact use case is eager key-many-to-one [10:10] which hibernate has an issue handling [10:11] the underlying issue is the inability to 2-phase load components the way we do for entities [10:11] fixing this has all kinds of repercussions [10:12] like ideally the fix should entail types finally being scoped to a session factory [10:12] (so that they know about it and have access to it) [10:12] just for the records - is this mapping JPA compliant or is specj using here some border case mapping? [10:12] we also need to add the notion of a "persister" for components [10:13] its totally jpa compliant [10:13] so we are just lucky that the TCK does not have a test for it? [10:13] it also opens up the door for other very cool component functionality like polymorhpic components [10:14] hardy_: its an intersection case, meaning you have to do (a) and (b) in conjunction [10:14] the tcks are almost always not testing all these combos [10:15] i see, thanks [10:15] anyway, this has to be in 3.6 [10:15] sounds hairy [10:15] the really question is to we add yet more band-aids to implement this [10:15] <-- epbernard has left this channel. [10:16] or do we do it the right way [10:16] the right way being redesigning how types work completely [10:16] do you have ideas about what type of bandaids could be applied? [10:16] --> epbernard has joined this channel (~epbernard@redhat/jboss/epbernard). [10:16] and where? [10:17] well the current band-aid approach being to change the Type API over time we need to to add SessionFactory/Session [10:17] this has been going on for years [10:17] is there a reason why we would not do the redesign? [10:17] and its the main reasin the type api is so unstable [10:17] time [10:17] resourecesx [10:17] its a major change [10:17] is there time for a slow and careful resource? [10:18] no :) [10:18] oh well [10:18] we cannot wait on this for 6+ months [10:18] which my gut tells me it would take :) [10:18] is that six months for you? [10:18] no [10:19] it would take me a month though probably [10:19] talking about the full type redesign [10:19] and thats best case (aka no more jira scares, no more website bs) [10:19] that sounds better than 6 months ;-) [10:20] thats just for the types [10:20] hardy_, I think he meant 6+ months for the slow and careful resource [10:20] then we still have the actual 2 phase load stuff [10:20] which again presents us with a choice [10:20] and osgi support in 3.6? [10:21] because the 2 phase load stuff could really use some general work [10:21] no [10:21] osgi is not for 3.6 [10:21] the problem with osgi is as soon as you ask anyone hat that means they have zero clue [10:22] "ok you want 'osgi support', how do i do that? what does that mean" [10:22] and then silence... [10:22] thats been my experience at any rate [10:22] plus we need to not bite off too much here [10:22] we are finally back to a good release cycle [10:23] i really do not want to go back to months between releases [10:23] granted 2 weeks is probably too often moving forward [10:23] though i think that was a great number overall for pre-releases [10:24] how did everyone else feel about the 2 weeks? [10:24] I liked it [10:24] i think 2 weeks was a little short [10:25] hardy_: curious why? [10:25] hardy_: for me too but I do't work full time on it so that totally explains it [10:25] we can try different numbers [10:25] maybe 4 weeks? [10:26] but personally from user perspective i think its better short during betas/crs [10:26] like i said we can try [10:26] imagine you are a user, though [10:26] and trying out these betas and crs [10:26] I think it we definitely should stick with regular releases and rather 2 weeks than stopping the good practice [10:27] well another option is to vary the number of weeks [10:27] maybe 4 or 6 weeks for alphas [10:27] 2 weeks through betas and crs [10:27] (or try 4 weeks here) [10:27] that sounds good [10:28] and beyond x.x.0.Final we should probably lengthen it a bit again [10:28] I think it is reasonable to have longer intervals for alphas, but once you are getting into betas and cr release you want to get the final release out asap [10:28] i dont know the optimal numbers [10:28] well you also want quick turn around to early adopters is more my concern [10:28] so they can find the next setof issues :) [10:29] i'll give you a great counter point [10:29] gradle [10:29] they have very long and inconsistent releases [10:29] early adopters could always use a SNAPSHOT [10:30] well thats a possibility *if* we get hudson publishing nightly builds [10:30] otherwise [10:30] whats really the diff [10:30] i need to do a release or do snapshot [10:30] sorting out Hudson seems to be good idea here [10:31] but there is really nothing to discuss on that [10:31] yes it needs to get fixed [10:31] but we also need some maven folks involved [10:31] timeInWeeksForNextRelease = 2*C*e(|x.x.0.Final-currentRelease|) [10:32] what i'd really like to see is to split the processes [10:32] (just a sum up of what you guys said basically), quick releases approaching final and slowing down the more we go further (before or after) [10:33] so that one hudson job does the build, and run the "default" db [10:33] epbernard: alphas will be longer too [10:33] yes because final-Alpha is close to 1 [10:33] :) [10:33] its like a 2-step/waltz :) [10:33] slow, quick, slow [10:34] anyway, i'd like to see one hudson job do build and run default db pushing nightly one success [10:35] then other jobs running the testsuite against the other dbs using that SNAPSHOT [10:35] sounds good to me [10:36] also, 3.6 do we merge annotations and entitymanager code into core module wise [10:36] the whole reason for the split in the first place was jdks diffs [10:36] one reason i don't like the current Hudson setup is that we never have some sort of warm feeling about having no tests failing [10:36] which will be gone moving forward [10:36] I don't think people are ready for that yet. A lot of people still ignore annotations and more specifically em [10:36] epbernard: ? [10:37] not sure what thats in reference to [10:37] There are 3 categories of users (pure core players, core + annotations, full entitymanager) [10:37] for them the split is as they expect [10:37] if you say so [10:38] do you see the constant questions about it? [10:38] i like the idea of moving em and annoations into core [10:38] When speaking I see a lot of non EntityManager users still [10:38] about 50% [10:38] i like it too [10:38] well i personally suggested just moving annotations [10:38] you said you wanted both [10:38] (though hey use older versions of Hibernate potentially so that adds a bias) [10:38] but it does not have a very high priority in my opinion [10:39] hardy_: (1) its easy (2) has implications in terms of hudson [10:39] so it needs to be decided [10:39] sebersole: Yes but I think I got cold feet becasue of the various talks I did [10:39] oh so i was right? ;) [10:40] yep :) [10:40] lol [10:40] this would help clean up the testing stuff too [10:41] so there are lots of pros here [10:41] (speaking out loud) that being said, if we merge core and ann, then em is a minor additional baggage as there is no additional dependencies I think [10:41] its a different api [10:41] third aprty dependency I mean [10:41] so in that respect its defendable i think [10:42] for sure i think core+ann should happen [10:42] em? eh i can go either way [10:42] i see both sides [10:42] epbernard: I think you should not think in lines of 'external' dependencies here [10:43] hardy_: expand [10:43] hardy_: what should line should we think of? [10:43] as you say - em is still a different API [10:43] relativistic lines I think ;) [10:43] anyways, just merging annotations seems fine as well [10:44] i also don't have any strong feelings regarding em [10:44] hardy_: right but I could argue that annoations are part of the JPA API [10:44] so lets say ann +1, em well lets all sleep on it [10:44] epbernard: thats not accurate [10:44] for certain [10:44] since one can use ann without jpa [10:45] its just a differen metadata facility [10:45] and the one we want to start directing people to use [10:45] hard to do that *and* not have it in the core jar imo [10:45] yes that was the initial merge reasoning [10:45] i think this is not the right way to look at it [10:46] the intial reason for it not being part of hibernate was jdks [10:46] that barrier is no more [10:46] thats how i am looking at this [10:47] ok, so to sub-total... [10:47] 1) yes keep time-boxing, but let investigate different imes [10:47] 2) 3.6 merge ann code into core module [10:48] 3) think through hudson and discuss with jcosta and maven fokks [10:49] anything else on those before we move on? [10:49] we only have a few minutes left in the hour so just trying to be efficient [10:49] go ahead [10:49] 3.... [10:49] 2.... [10:49] 1.... [10:49] ok [10:49] docs [10:50] 2 points here: [10:50] 1) consolidation of the numerous manuals [10:50] 2) beautifying the docs website [10:50] hardy_: you and i had discussed (2) before [10:50] you remember the details? [10:51] i have the design team ready to help out with style [10:51] imho if you start considering specj that's very cool but you will be glad to have a hudson cuntinually running perf tests for you [10:51] if i remember correctly we talked about a landing page for the docs [10:51] i remember the main idea was index.html pages rather than dir listing [10:51] and we also discussed on which doc version should be uploaded and how [10:52] that part is still undecided, i need to follow up with the jboss.org team [10:52] we need an index.html at least for http://docs.jboss.org/hibernate/ [10:52] nto sure if you noticed but for the ann/em javadocs i used symlinks now to point to the aggregated javadocs [10:53] anyone else having trouble building javadocs? [10:54] sebersole: nope, I haven't looked yet. just getting back into action ;-) [10:54] Regarding the docs we should document somewhere how we want to do this now. [10:54] hardy_: for which part? [10:54] "Regarding the docs" is a large-ish topic ;) [10:54] regarding which versions of the docs should be available [10:55] anyone want to volunteer for the consolidation part? [10:55] hardy_: i do not have a good answer for that [10:56] For the consolidation plan, one way to approach it is to: [10:56] i think the main concerns were around 'searchability' via google [10:56] - check if we can take Annotations and merge it as a chapter in Core [10:56] when i asked about directing bots and crawlers as to which directory to index i was told to wait [10:56] we would ahve hbm and annotations as separate chapters [10:57] epbernard: yes thats one option [10:57] and merge the set up considerations [10:57] sebersole: he, he - never got this answer before ;-) [10:57] That would be the less disruptive probably [10:57] EntityManager is a more complex beast [10:57] another is to use annotations as the main reference [10:57] it has lots of duplicates [10:57] and splitting is likely not a good option [10:58] and point to hbm alternatives [10:58] (as an index etc) [10:58] Like Java Persistence With Hibernate? [10:58] i have not seen it [10:58] so hard to say [10:58] <-- AnthonyHib has left this server (Quit: Leaving.). [10:58] sebersole, is there anyone on the docs team available to do the consolidation? [10:58] ie each feature is described both in annotations and hbm options int he same section [10:59] perhaps [10:59] though tbh i think we describe things a tad too low-level usually in the docs as is [11:00] most noobs dont know the xml attribute they are looking for [11:00] which is how the docs present it [11:00] annotations is a tiny bit more use case oriented but not by much :) [11:00] gbadner: i seriously doubt it [11:00] never hurts to ask [11:01] (unless you are weary of heaing 'no') [11:01] sebersole: gbadner not if you don't have hope at least :) [11:01] sebersole, any money available for a contractor? [11:01] i'd rather not go that route tbh [11:02] ok [11:02] we can put off the git/hg, maven/gradle discussions i guess ;) [11:03] i know epbernard was so looking forward to them :D [11:03] ;) [11:03] :) [11:03] anything else y'all want to cover today? [11:04] how do you sum up the doc consolidation so far? [11:04] tbd? [11:04] ;() [11:04] you mean the approach? [11:05] well i'd like, at the same time, to make it more case specific [11:05] yes, agreeing on the approach would be a first step [11:05] hardy and I are going to fight and decide which of the two tries the merge ann into core approach [11:05] that is likely a 3 days job or something liek that [11:05] (considering the motivation :) ) [11:05] the fight? [11:05] :) [11:06] 3 days is a colossal battle [11:06] It makes sense that either Hady or me do it [11:06] due to the ann knowledge [11:06] jupp, makes sense [11:06] I am talkinga bout the first curt [11:06] well if we take the approach of simply merging i think its fine [11:06] form there we will see if tthat makes sense (structure wise) [11:06] we also need to consider the jbc ref for example [11:07] if it does not that's going to be an uphill battle [11:07] jbc ref? [11:07] jboss cache [11:07] jboss cache [11:07] :) [11:07] eventually i see an appendix per each major intg [11:08] not sure if appendix is the correct presnetation medium [11:09] maybe the fight loser could work on the docs server index.html pages? [11:09] sebersole: you mean the generation of these? [11:10] By Maven? [11:10] writing them yes [11:10] no [11:10] Otherwise the split would ahve been obvious ;) [11:10] why onearth would i want to add *more* maven deps? [11:10] ;) [11:10] he he [11:10] i can look into the index.html stuff [11:10] epbernard: i mean index.html pages for http://docs.jboss.org/hibernate/ [11:10] that should not be too hard [11:11] speaking of which [11:11] james and cheyenne are ready to help with css, images etc [11:11] I like the structure we ahve [11:11] sebersole: didn't you say that you have some design people who can help us? [11:11] just give them a shout hardy_ [11:11] ie each module has a module/version/ approach [11:11] hardy_: [11:11] james and cheyenne are ready to help with css, images etc [11:11] and stable use symlinks to point to the latest version of each module [11:11] stable/module [11:11] jupp, saw it now [11:12] though module/stable would work too [11:12] epbernard: provided the indexing issues get addressed [11:12] well [11:12] if you don't point to the non stable data [11:12] ? [11:12] Google is less likely to promote it [11:13] if there are no / few links to say search/3.1 compared to search/stable [11:14] i almost always use the version version [11:15] IMO, the best approach to control indexing by search engines would be the robots file, but that might be tricky since we don't have access to it [11:16] yes but that's too easy [11:17] ;) [11:19] ok, thats all i had for this week [11:19] (well there is more but its already been 80 minutes) [11:20] so anything else? [11:20] so from now on every Monday same place same time? [11:21] yessir