[hibernate-dev] Weekly meeting (4/19)

[Steve Ebersole]

First meeting.  Went well.  

1) We discussed our experiences with time-boxing in the 3.5 releases.
Generally positive.  Some felt 2 weeks may have been a bit too often.
We will play with time moving forward to find the best balance which may
be an alternation: slow (alphas), fast (betas and crs), slow (past
final).

2) 3.6
2.a) will require at least JDK 1.5
2.b) merge annotation code into core module
2.c) will revist the idea of merging entitymanager into core module
during next meeting.
2.d) specj use case (eagerly loaded key-many-to-one)

3) Hudson plan

4) Documentation consolidation (core, annotations, jbc, envers,
entitymanager)

5) docs.jboss.org issues.  Archiving release docs versus indexing
engines.  index.html pages.

I have attached the log.

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