21:13:45 <lightguard_jp> #startmeeting
21:13:53 <jbott> Meeting started Wed Apr 27 21:13:45 2011 UTC.  The chair is lightguard_jp. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:13:53 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:14:04 <lightguard_jp> #chair mojavelinux
21:14:08 <jbott> Current chairs: lightguard_jp mojavelinux
21:14:08 <jbossbot> git [12core] push 10master7 fa5b2d1.. 6Lincoln Baxter, III Added 'wait' plugin for scripting convenience
21:14:12 <jbossbot> git [12core] push 10master URL: http://github.com/forge/core/compare/75acf61...fa5b2d1
21:14:27 <kenfinnigan> lincolnthree: were you waiting for the mtg to start before committing that?
21:14:32 <lincolnthree> meeting?
21:14:38 <lincolnthree> oh..
21:14:42 <lincolnthree> right
21:15:24 <mojavelinux> of course he was, he needs to earn his vanity badge
21:15:39 <mojavelinux> #topic Report on action items from last meeting - Jason
21:16:23 <lightguard_jp> Sorry
21:16:36 <lightguard_jp> #info All action items from last week have been finished
21:16:47 <lightguard_jp> The modules that requested JIRA integration have it
21:17:07 <kenfinnigan> how's the testing of that going? working well?
21:17:12 <lightguard_jp> Please feel free to try it out, you may need to use [ISSUE-###] format
21:17:18 <lightguard_jp> I haven't done any yet.
21:17:40 <lightguard_jp> You may also notice a new JIRA about formatting
21:17:48 <lightguard_jp> We're trying to get all the formatting done by the 1st
21:18:01 <lightguard_jp> Leads, please do your best to make that happen.
21:18:27 <mojavelinux> rank and file for jbw :)
21:18:31 <lightguard_jp> I think I got all the modules that had formatting issues, but may have missed some, please double check your module if you don't have a JIRA for formatting
21:18:48 <mojavelinux> and forge should use the jboss community formatting :P
21:18:59 <mojavelinux> all aboard
21:19:04 <lincolnthree> yes sir
21:19:08 <lincolnthree> very good sir
21:19:20 <lincolnthree> right away sir
21:19:24 <lightguard_jp> Also emails for pull requests should go out now for each module
21:19:29 <mojavelinux> that's the price of using danternet
21:19:34 <lightguard_jp> But only to the one who authored the code :)
21:19:47 <antoine_sd> formatting only concern java files ? or are there rules for pom and other xml files too ?
21:19:52 <bleathem> I noticed the reference docs are still using the old fomratting in the example codes bits, we should make an effort to update those too
21:20:08 <mojavelinux> yes, good point
21:20:14 <lightguard_jp> We don't have any rules listed, but I think it's three spaces?
21:20:19 <sbryzak> lightguard_jp: does that mean the module lead won't get an e-mail notification for pull requests?
21:20:38 <mojavelinux> no, it's the thank you when the pull request is merged
21:20:49 <mojavelinux> or, in github terms, closed
21:20:53 <lightguard_jp> It's a thank you email to the original author
21:20:57 <sbryzak> ah, no problem
21:21:20 <sbryzak> that's a nice touch
21:21:26 <mojavelinux> yes, this is a very important step to a) showing appreciation and b) keeping the author in the loop, hence keeping the conversation going
21:21:30 <mojavelinux> indeed
21:21:34 <lightguard_jp> I'm sure we could jazz it up a bit more, but it works :)
21:21:39 <mojavelinux> #info source code formatting should apply to code in docs
21:21:45 <lightguard_jp> First bit of python code for me, not too bad :)
21:21:52 <mojavelinux> #info XML files also get 4 spaces, no tabs
21:22:17 <lightguard_jp> We need to document that
21:22:24 <lightguard_jp> In build and on the site too
21:22:30 <lightguard_jp> Any takers?
21:22:45 <mojavelinux> that is on the site
21:22:58 <lightguard_jp> Okay, we need to update the info in build as well
21:23:03 <lightguard_jp> the build module*
21:23:19 <mojavelinux> http://seamframework.org/Seam3/DevelopmentGuidelines
21:23:24 <lightguard_jp> Not sure if that info is exported in eclipse and netbeans
21:23:45 <bleathem> I think it's default in netbeans (4 spaces in XML)
21:23:52 <mojavelinux> might not be, I've never understood why IDEs (particularly eclipse) only have formatting profiles for Java, seems shortsighted
21:23:58 <mojavelinux> yep, it's the default in netbeans
21:24:20 <mojavelinux> one of the main reasons we are choosing these settings is that they are close, if not the actual, default
21:24:24 <lightguard_jp> IDEA has profiles for all sorts of langs
21:24:31 <mojavelinux> idea ftw!
21:24:35 <mojavelinux> :)
21:24:40 <lightguard_jp> I think it's default in IDEA as well
21:24:44 <lightguard_jp> Good thing Max isn't here ;)
21:24:48 <bleathem> I plan on giving IDEA a try real soon
21:24:53 <mojavelinux> hahaha
21:25:12 <mojavelinux> the guidelines could use note about jira reference in commit message
21:25:36 <lightguard_jp> bleathem: Ask Dan for a licence for Seam work
21:26:46 <lincolnthree> bleathem: have you tried JBoss Tools?
21:26:55 <mojavelinux> should be 4
21:27:00 <bleathem> yes, it has only one problem
21:27:04 <lightguard_jp> We need to at least not the action item, hopefully someone will volunteer for it :)
21:27:08 <bleathem> it's built on eclipse :P
21:27:13 <mojavelinux> oops, ignore that
21:27:23 <mojavelinux> max's team has drastically improved the quality of the eclipse tooling, no question about it
21:27:28 <mojavelinux> from the maven plugin to the cdi experience
21:27:50 <mojavelinux> not saying necessarily there isn't anything better, but I commend his team's work, they definitely have the right vision now
21:28:04 <mojavelinux> and that's a good start
21:28:31 <mojavelinux> but I'm also excited to have tooling that is agnostic of IDE (**forge**)
21:28:40 <mojavelinux> is that all from last week followup?
21:28:52 <lightguard_jp> #action the information in the build module needs to reflect spacing for xml files
21:28:57 <lightguard_jp> Yep, I'm good
21:29:02 <mojavelinux> #topic Seam Spotlight - Shane
21:29:22 <sbryzak> oh, i'm up
21:29:43 <sbryzak> so, we're looking for a few more volunteers to write spotlight articles
21:30:22 <sbryzak> so far we've had jason, john
21:30:29 <sbryzak> and brian
21:30:42 <sbryzak> i think gunnar volunteered to do the next one
21:30:51 <sbryzak> however we have no-one lined up after that
21:31:07 <sbryzak> so, any takers?
21:31:14 <lightguard_jp> Dan could write up about some of the cool events in the servlet module ;)
21:31:38 <sbryzak> i could probably do one for remoting
21:31:50 <lightguard_jp> Or security
21:31:56 <sbryzak> right
21:32:00 <bleathem> +1 for security
21:32:07 <lightguard_jp> security is probably used more / has more questions right now
21:32:12 <sbryzak> also, their being on in.relation.to is a temporary hosting solution
21:32:18 <sbryzak> ok, security it is then
21:32:28 <mojavelinux> +1 for security
21:32:33 <lincolnthree> +1 security
21:32:37 <bleathem> I'd like to read one on Seam Persistence
21:32:41 <lightguard_jp> We should also reach out to the Errai team and see if they have someone who would like to write about CDI integration
21:32:46 <lincolnthree> would like to see a "get started" example
21:32:54 <sbryzak> speaking of which, has anyone seen stuart online recently?
21:33:01 <lightguard_jp> Nope
21:33:06 <mojavelinux> I can do one on persistence, though not until a week after jbw (I need to find my sanity again)
21:33:10 <bleathem> holidays I think
21:33:14 <sbryzak> ah
21:33:21 <sbryzak> well cbrock could write one for errai/cdi
21:33:33 <mojavelinux> that would be good, also christian could do one
21:33:37 <mojavelinux> he did this
21:33:42 <lightguard_jp> stuart was last seen on IRC almost two weeks ago
21:33:46 <sbryzak> i'm sure a lot of people would find it interesting
21:33:51 <mojavelinux> http://errai-blog.blogspot.com/2011/04/latest-enhancements-to-errai-cdi.html
21:34:00 <sbryzak> ah
21:34:04 <mojavelinux> but I don't think people are finding those entries, we could always syndicate them both places
21:34:08 <sbryzak> this is exactly why we need the seam university site
21:34:14 <mojavelinux> that entry needs a bit more meat
21:34:19 <sbryzak> to collate all these blogs that are spread out everywhere
21:34:52 <lightguard_jp> #action sbryzak will author the seam spotlight on Seam Security
21:34:56 <sbryzak> ok, so any takers for writing the next article after security?
21:35:19 <bleathem> persistence would be good, of mojavelinux or stuartdouglas want to write one
21:35:26 <lightguard_jp> That's two weeks, right?
21:35:31 <mojavelinux> I'll do one for persistence after that (or stuart if I can manage to delegate it to him)
21:35:46 <sbryzak> yep, we have validation this week, then security
21:35:54 <sbryzak> so i'll lock in persistence after that
21:35:59 <mojavelinux> plus, I've recently done some work with persistence in my cdi tutorial, so i can just port that likely
21:36:04 <sbryzak> and either dan or stuart can write it
21:36:09 <lightguard_jp> #action mojavelinux or stuartdouglas will write about Seam Persistence next
21:36:34 <lightguard_jp> We should see if we can get Jozef to done one on Rest
21:37:32 <mojavelinux> perhaps we should have either a wiki page or google calendar to keep track of this pipeline
21:37:45 <lincolnthree> sorry
21:37:49 <jbossbot> git [12core] push 10master7 a998d40.. 6Lincoln Baxter, III Updated wait plugin output format
21:37:54 <jbossbot> git [12core] push 10master URL: http://github.com/forge/core/compare/fa5b2d1...a998d40
21:37:58 <bleathem> it's tracked in the minutes
21:38:02 <mojavelinux> we can keep it semi-private if you don't want to build up expectations unnecessarily
21:38:06 <mojavelinux> right, I just mean a longer pipeline
21:38:55 <mojavelinux> i'll follow up on that
21:39:05 <kenfinnigan> to me this sounds like it kind of falls into dev methodologies in the sense that we need an area to "plan" that is either private or semi so
21:39:36 <bleathem> nice segway into the next topic kenfinnigan
21:39:41 <bleathem> :)
21:39:46 <mojavelinux> hahah
21:39:50 <mojavelinux> #topic Briefly discuss development methodologies (please come prepared to discuss methodologies that you have used which worked)
21:40:10 <bleathem> + 1 for waterfall.  We need design specs people!
21:40:20 <lightguard_jp> This will be further talked about next week at JUDCon for those attending
21:40:36 <mojavelinux> so it's become fairly obvious in recent discussions reflecting on the state of seam that we have pretty much been shooting from the hip for about...forever
21:40:52 <kenfinnigan> very true
21:41:14 <lightguard_jp> It was fine when it was just a slow moving JBoss only project
21:41:21 <sbryzak> as long as any methodology we choose doesn't have much overhead
21:41:28 <sbryzak> remember, we have limited resources
21:41:35 <lightguard_jp> We now have over 20 (over 30?) modules and it's simply not working well anymore :)
21:41:55 <mojavelinux> now, it's very important to keep the perspective that this is a community project and by no means do we want to get all bossy on people
21:42:01 <lightguard_jp> Right, we need something easy to use / follow with minimal touch points
21:42:06 <mojavelinux> so agile is the word
21:42:13 <lightguard_jp> And it works with a distributed team
21:42:18 <antoine_sd> +1 agile
21:42:28 <kenfinnigan> +1 agile, or variation there of#
21:42:43 <lightguard_jp> agile is a buzzword though. Which form of agile?
21:42:54 <sbryzak> agile has a whole heap of principles
21:42:58 <mojavelinux> but I think where we are breaking down is that it's actually quite inconvenient for part-time volunteers that we don't have any real target points, then all of a sudden we have a super urgent one
21:43:05 <sbryzak> we need to be specific about which ones we want to adopt
21:43:09 <lightguard_jp> Does anyone have suggestions that have worked well for them in the past?
21:43:26 <mojavelinux> I actually watched a presentation recently that made a ton of sense, and really spawned this idea
21:43:31 <sbryzak> RUP!  (only kidding)
21:43:36 <mojavelinux> and in reflection, actually solved our problem directly
21:44:10 <mojavelinux> in the past, we have made promises of target dates, then had no real plan to actually get there
21:44:15 <mojavelinux> in this talk
21:44:19 <kenfinnigan> is the presentation on the web that you can pass around?
21:44:58 <sbryzak> of course we had a plan... work our asses off to meet our deadlines
21:45:06 <sbryzak> it worked ;)
21:45:14 <bleathem> I like the idea of fixed timebox releases
21:45:19 <lightguard_jp> Not very sustainable though :)
21:45:23 <mojavelinux> the speaker was saying that the idea is that set some goals, iterate (for a period of time) then revisit those goals, but two things are important
21:45:28 <bleathem> people like regular release schedules
21:46:09 <mojavelinux> 1. don't assume that over time you will get better at estimating, because the fact is, the creative process just isn't that predictable
21:46:27 <mojavelinux> 2. stay consistent with your iterations, but not necessarily forcing every feature you hoped in
21:46:43 <kenfinnigan> can relate to 2
21:47:18 <mojavelinux> so the timebox release does seem to be the recommended way
21:47:22 <bleathem> I'd say we're better off having a larger number of smaller releases, than waiting for big catch-all releases
21:47:27 <bleathem> a la Jenkins
21:47:34 <bleathem> but maybe not to that extreme :P
21:47:45 <mojavelinux> then, also, people can plan their schedule for these releases
21:47:49 <sbryzak> that's essentially the plan anyway
21:47:55 <sbryzak> our bundled releases are due every 6 months
21:48:00 <kenfinnigan> +1 to smaller but regular releases
21:48:11 <sbryzak> they include whatever latest versions of modules are available at the time
21:48:16 <mojavelinux> just as an example, I think Ubuntu is popular largely because every 6 months, like clockwork, you know you are going to get something new
21:48:29 <lightguard_jp> sbryzak: First time I've heard that 6 mo release schedule
21:48:43 <sbryzak> so it's up to each module lead to get a release out before the bundled release date, if they have new features or bug fixes
21:48:48 <mojavelinux> right, but I think our modules should release at least 2 - 4 times in that period
21:48:52 <mojavelinux> maybe 2 -3, not sure the exact number
21:48:58 <sbryzak> i think that's highly dependent on the module
21:49:06 <bleathem> a lot depends on the volatility of the module though
21:49:10 <sbryzak> if a module is mature, it may have no releases
21:49:14 <sbryzak> e.g. seam-servlet
21:49:23 <bleathem> some modules will become feature complete at some point, no?
21:49:33 <mojavelinux> well, naturally, yes
21:49:37 <sbryzak> bleathem: exactly my point
21:49:41 <kenfinnigan> is there ever such a thing as feature complete?
21:49:49 <mojavelinux> so perhaps it's more that we should round robin module releases every 2 weeks or so
21:49:54 <kenfinnigan> there's always something new to add on
21:50:03 <sbryzak> i think in some cases, yes a module can be feature complete
21:50:07 <mojavelinux> kind of like with the spotlight, we always have activity
21:50:15 <sbryzak> for example, a module that integrates spring with cdi
21:50:24 <mojavelinux> and for those interested in multiple modules, it gives you a chance to change up your focus
21:50:28 <sbryzak> once it works, there's no requirement for any additional features
21:50:49 <bleathem> mojavelinux: more inter-module development would be good.  They are turning into silos
21:50:54 <mojavelinux> i think that point could be argued, but let's just assume it will or it won't
21:51:03 <mojavelinux> yeah, so perhaps we can start by saying
21:51:07 <kenfinnigan> with a move to short releases cycles, I would propose we also need to re-evaluate the release process with a view to streamlining it
21:51:19 <mojavelinux> let's have a module release every 2 weeks on avg (to start, we can see if this is too long or short)
21:51:31 <mojavelinux> sorry, at least one
21:51:51 <bleathem> some modules have only one person committing changes.  2 weeks might be a little steep in those cases
21:52:06 <mojavelinux> let me clarify furthur
21:52:18 <sbryzak> i think that saying we'll have a module release every 2 weeks is putting an artificial constraint on our modules
21:52:27 <bleathem> maybe we can recommend a range, and the individual modules can make their own committment to a regular release schedule inside that range
21:52:38 <mojavelinux> of all the seam modules, we should have at least one module release happen every two weeks
21:52:43 <mojavelinux> that's 1 goal
21:52:51 <lightguard_jp> In two weeks we have a servlet release, then in two more we have a catch release, then in another two have a faces release, that's six weeks for faces to get things ready, probably plenty of tim
21:52:55 <lightguard_jp> time*
21:53:05 <mojavelinux> yes, exactly
21:53:11 <mojavelinux> now, that's a goal, not a restriction
21:53:23 <sbryzak> it's a goal for the sake of appearances though
21:53:28 <mojavelinux> that keeps things happening, and something that jason, shane and I can keep an eye on
21:53:44 <sbryzak> i think we need to evaluate this on a per module basis
21:54:28 <lightguard_jp> Is this enough to strike up a larger conversation next week?
21:54:34 <mojavelinux> I don't think it's arbitrary, because it keeps people interested in seam and keeps encouraging people to participate
21:54:40 <lightguard_jp> Sounds like we have an idea where we want to go
21:54:45 <mojavelinux> by all means, this is just the start of the conversation on this
21:54:50 <lightguard_jp> didn't have to have a full solution this meeting
21:54:58 <sbryzak> sure, let's continue it over the next week or so
21:55:04 <mojavelinux> nope, so that should get you thinking
21:55:08 <bleathem> yes, plenty of food for thought
21:55:12 <mojavelinux> a document would be good
21:55:17 <mojavelinux> brainstorming
21:55:25 <lightguard_jp> We didn't have any infos
21:55:29 <bleathem> lightguard_jp: do we want to record any of these ideas in the minutes?
21:55:35 <lightguard_jp> Should probably put something in the notes so we don't lose it
21:55:40 <lightguard_jp> :)
21:55:45 <mojavelinux> working on it...
21:55:50 <lightguard_jp> Okay
21:56:13 <sbryzak> btw, jozef has (possibly) volunteered to lead the compatibility module
21:56:17 <mojavelinux> #info we plan to release the seam stack every 6 months, but we need to est the first target date
21:56:24 <sbryzak> however i don't think we're going to be able to implement the way we originally planned
21:56:40 <sbryzak> because of the class conflicts issue
21:56:54 <lightguard_jp> Ah, for Seam2 compat
21:56:59 <mojavelinux> #info we are considering setting a goal that we have at least one module release happen every two weeks to keep seam active and to give community new bits
21:57:03 <sbryzak> yes
21:57:07 <mojavelinux> fantastic!
21:57:20 <sbryzak> the original strategy was to just deploy the seam 2 app inside of a cdi container
21:57:28 <sbryzak> and allow bi-directional DI between Seam 2 and CDI
21:57:49 <sbryzak> that would allow the developer to gradually convert his seam 2 components to CDI beans
21:57:53 <sbryzak> however
21:58:11 <sbryzak> what we didn't consider was that there would be a conflict in classes
21:58:19 <sbryzak> many of the seam 2 classes exist in seam 3 also
21:58:30 <sbryzak> e.g. org.jboss.seam.security.Identity
21:58:35 <sbryzak> there's many others
21:58:39 <kenfinnigan> bummer
21:58:43 <bleathem> I guess a package rename for Seam2 would be out of the question?
21:58:48 <mojavelinux> #info we are looking for other ideas that would make the seam development process more tangible, but which would respect the distributed nature of the team and the volunteer-based membership
21:58:57 <sbryzak> yes, a package rename won't work
21:59:04 <sbryzak> so we're back to plan A
21:59:14 <kenfinnigan> that would mean the app would have to be re-written that uses Seam 2
21:59:25 <sbryzak> which is for the compatibility module to process all the seam 2 components and shoe-horn them into CDI
21:59:46 <bleathem> lots of questions last night at VanJUG re: migrating from Seam 2
21:59:50 <sbryzak> i don't see any major problems doing it this way, it's just more work
21:59:55 <mojavelinux> jboss modules perhaps?
22:00:09 <lightguard_jp> My job just got harder
22:00:13 <bleathem> mojavelinux: good idea to explore at JUDCon
22:00:20 <bleathem> mojavelinux: JBoss modules that is
22:00:24 <mojavelinux> indeed
22:00:46 <mojavelinux> two more topics, one quick one, speaking of judcon
22:00:56 <sbryzak> anyway, i'll write up an e-mail for seam-dev and we can discuss it further there
22:01:01 <mojavelinux> #info next week's meeting
22:01:05 <mojavelinux> oops
22:01:09 <mojavelinux> #topic next week's meeting
22:01:49 <mojavelinux> #info no meeting next week on IRC, but for those at JUDCon, we will have an informal gathering/brainstorm/meeting after the hackfest monday ~21:30ish
22:02:22 <mojavelinux> we might even start during the hackfest...I'm looking at places where we can get a section of the bar/restaurant for eats, drinks and good times
22:02:30 <mojavelinux> #topic git workflow
22:02:38 <mojavelinux> Briefly discuss git workflows (possibly looking at implementing http://nvie.com/posts/a-successful-git-branching-model/)
22:02:57 <mojavelinux> now that we aren't in complete alpha/crisis mode, we can slow down and take branches more seriously in git
22:03:12 <mojavelinux> the URL proposes a really clean way to manage the development branch for modules
22:03:28 <bleathem> agreed, official feature braches would be useful
22:03:36 <mojavelinux> lightguard_jp: is going to pilot it in catch, feel free to give it a go for your module
22:03:43 <mojavelinux> it's something that totally sucked in SVN
22:03:48 <mojavelinux> and now that we have git, it's finally possible
22:03:58 <bleathem> can you add that link to the minutes?
22:04:03 <kenfinnigan> that would then allow collaboration on a feature in a branch correct?
22:04:15 <mojavelinux> #link git workflow proposal http://nvie.com/posts/a-successful-git-branching-model/
22:04:19 <mojavelinux> absolutely
22:04:25 <kenfinnigan> that is cool
22:04:29 <lightguard_jp> #link http://nvie.com/posts/a-successful-git-branching-model/
22:04:34 <mojavelinux> #info it would allow collaboration on a branch, and it will keep master stable
22:04:41 <antoine_sd> I like it
22:04:54 <lightguard_jp> mojavelinux: uri first, then desc
22:05:02 <lightguard_jp> It's backwards
22:05:06 <kenfinnigan> so that master branch only ever has commits for the release?  am i reading that right?
22:05:14 <lightguard_jp> Yep
22:05:23 <kenfinnigan> like that idea
22:05:27 <lightguard_jp> Mostly they'll be merge commits and maven spam
22:05:48 <mojavelinux> yep, and ci should likely build from develop
22:05:57 <mojavelinux> because master will be a tag, and that's already tested
22:06:06 <lightguard_jp> Ah, good point
22:06:12 <lightguard_jp> I need to change that in catch
22:06:16 <mojavelinux> #info ci should build from develop in this proposed git workflow
22:06:30 <mojavelinux> okay, we are going long, so we'll wrap it up
22:06:35 <mojavelinux> one last topic/recommentation
22:06:39 <mojavelinux> #topic documentation
22:06:49 <mojavelinux> if you haven't watched it yet, see http://blip.tv/file/4881071
22:06:56 <mojavelinux> #link http://blip.tv/file/4881071 writing good documentation
22:07:11 <mojavelinux> it's not the same old song and dance
22:07:15 <lightguard_jp> Max posted that on twitter a couple of weeks ago, very great presentation about documentation
22:07:19 <gastaldi> hello !
22:07:25 <lightguard_jp> gastaldi: Hey, welcome
22:07:38 <mojavelinux> it basically gives you an appreciation for the fact that if you don't document it, you might as well not wasted your time writing it
22:07:43 <bleathem> yikes, getting homework from the Seam community meetings!
22:07:47 <mojavelinux> because it's just the same as if it doesn't exist
22:07:51 <gastaldi> lightguard_jp: Thanks ! How ´re doing ?
22:07:56 <mojavelinux> :)
22:08:00 <mojavelinux> I'll mention one point that he doesn't
22:08:05 <gastaldi> mojavelinux: I heard that your presentation was great
22:08:09 <mojavelinux> #info writing documentation/blogs makes you famous and get jobs :)
22:08:13 <kenfinnigan> true, no point having a feature if no one knows its there
22:08:18 <mojavelinux> hehehe
22:08:22 <lightguard_jp> gastaldi: still in the community meeting, one sec
22:08:26 <gastaldi> nop
22:08:52 <lightguard_jp> #idea We should probably schedule a documentation review soon
22:09:05 <lightguard_jp> sbryzak: Did we ever hear anything from the doc team at Red Hat?
22:09:14 <mojavelinux> indeed, that will be something jason you can I can start with, then when organized, take it to the team
22:09:29 <mojavelinux> okay, gotta roll, there are drinks beaconing :)
22:09:39 <kenfinnigan> lucky you!
22:09:43 <mojavelinux> plus, gotta go talk up all the great work you guys have done
22:10:00 <sbryzak> lightguard_jp: they didn't get around to reviewing our docs
22:10:08 <lightguard_jp> doh
22:10:23 <antoine_sd> about writing doc. Do you guys have resources on docbook
22:10:29 <mojavelinux> arquillian talk went great at ete, tomorrow lincoln and I showcase java ee 6, cdi and forge!
22:10:38 <antoine_sd> tools, helpers, etc..
22:10:51 * lightguard_jp stepping away for a sec
22:10:57 <mojavelinux> that's a good question antoine_sd and something that would be good for the handbook
22:11:06 <mojavelinux> just talked to ken rimple and he praised oxygen
22:11:11 <mojavelinux> not free though
22:11:16 <mojavelinux> i've used serna and it's very good as well
22:11:30 <antoine_sd> I saw topics on the ml long ago on the subject
22:12:27 <kenfinnigan> mojavelinux: is meeting closed?
22:12:34 <mojavelinux> #endmeeting