(13:16:28) nichoj: well then, perhaps we should get this party started
(13:16:47) fordfrog: nichoj: do you know what's with Caster?
(13:16:59) nichoj: he isn't able to make it
(13:17:07) fordfrog: ah
(13:17:37) nichoj: so, I'm going to assume you guys can read the updates of what people have been up to on your own
(13:17:56) nichoj: if there's anything related to that that people want to discuss about those ongoings, we can bring them up at the end of the meeting
(13:18:07) christel: oooh, am i at another java meeting? LD
(13:18:08) christel: :D
(13:18:18) sanchan: christel: yes
(13:18:22) christel: excellent!
(13:18:46) sanchan: nichoj: my done/todo list is quite unchanged
(13:18:50) sanchan: since last meeting
(13:19:02) sanchan: I've worked on popt and beecrypt
(13:19:06) nichoj: sanchan: alright. mind just pointing that out on the agenda
(13:19:28) nichoj: so... announcements
(13:19:47) sanchan: nichoj: I don't think I've access to overlays.gentoo.org
(13:19:49) nichoj: the new java system is stable on all platforms we support java on, ie x86, ppc, ppc64, amd64, and ia64
(13:20:03) wltjr: woot
(13:20:09) nichoj: sanchan: alright, we can get that fixed afterwards
(13:20:16) sanchan: ok
(13:20:37) nichoj: not too much else to say about that, aside from as wltjr said, w00t
(13:21:00) nichoj: according to our contact at sun, Java 1.6 is expected sometime in December
(13:21:12) Betelgeuse: nichoj: Any new about 1.5.0.09?
(13:21:17) nichoj: ah, good point
(13:21:31) ali_bush: the transistion seems to have gone very smoothly
(13:21:45) nichoj: in the bump request, someone pointed out a bug they filed upstream, and sounds like there are issues with releasing it...
(13:22:57) nichoj: https://jdk-distros.dev.java.net/issues/show_bug.cgi?id=17
(13:23:12) Betelgeuse: nichoj: Well it seems I could download the file by changing the url ;D
(13:23:18) Betelgeuse: So it is there.
(13:23:19) nichoj: really?
(13:23:23) Betelgeuse: The website is just lagging.
(13:23:24) Betelgeuse: ;D
(13:23:27) nichoj: sonofa
(13:24:14) Betelgeuse: problem solved...
(13:24:40) nichoj: in related news, there are some wild rumors floating around that java will be open sourced real soon (tm)
(13:24:44) nichoj: and that it could be GPL'd...
(13:25:22) jerry: having some difficulties with subversion, it fails to install, errors with Cannot compile JavaHL without a suitable JDK, prior had java-config-1.3.7, but that was blocking..
hesshess heuristik
(13:26:07) jerry: so I emerge -C that java, now this error crops up and emerge -p jdk wants to reinstall java-config-1.3.7
(13:26:13) nichoj: jerry: we're in the middle of a meeting at the moment... mind checking back in an hourish?
(13:26:14) wltjr: jerry: ask in about 30 min to 1 hr, plz we are having a meeting
(13:26:25) jerry: sorry
(13:26:33) wltjr: jerry: np, ty
(13:26:50) nichoj: let's see... ant-1.7 is coming
(13:26:59) wltjr: so is tomcat 6.0
(13:27:18) wltjr: and servletapi 2.5 and etc
(13:27:28) fordfrog: in fact ant is rc1 already
(13:27:39) fordfrog: not beta
(13:27:47) Betelgeuse: So are we going with split ant on 1.7?
(13:27:55) nichoj: not to discount tomcat, but ant has a signficantly bigger impact on our packages :)
(13:27:57) nichoj: like most of em
benny`work Betelgeuse
(13:28:03) nichoj: Betelgeuse: that is the hope
(13:28:07) Betelgeuse: good
(13:28:32) nichoj: so, I recommend people start using caster's split-ant-overlay for testing
(13:28:53) nichoj: we should also review how it is implemented
(13:29:02) nichoj: I personally haven't looked at it since it's infancy
(13:29:15) Betelgeuse: I haven't either.
(13:29:41) fordfrog: is there some dev docs for new ant or nothing changes from the pov of ebuilds?
(13:29:57) Betelgeuse: fordfrog: DEPS change as you dep only on the tasks you need.
(13:29:59) nichoj: there were a few bugs in ant that affected some of our packages
(13:30:07) nichoj: ie how it handled filesets
(13:30:16) nichoj: which affected commons-logging as I recall
(13:30:39) fordfrog: Betelgeuse: but it still has backward compatibility so you can dep on ant-tasks
(13:30:47) Betelgeuse: fordfrog: Hopefully, yes
(13:30:57) nichoj: I'd imagine we'd do something similar to xorg going modular
(13:31:06) fordfrog: Betelgeuse: sure, I use ant 1.7 and ant-tasks for nb ebuild
(13:31:11) nichoj: ie || ( ( list o modular tasks) ant-tasks)
(13:31:38) Betelgeuse: nichoj: Yeah, I think that is fine
(13:31:40) nichoj: the benefit here being that the package's stabilization wouldn't depend on ant's stability
(13:31:57) nichoj: like there was a thought of just converting new ~arch packages
(13:32:13) fordfrog: will the build.xml overwrite be no more needed?
(13:32:19) nichoj: fordfrog: good question
(13:32:31) nichoj: actually, they support something like -Djavac.target=something
(13:32:40) fridrik: nice
(13:32:47) nichoj: I had filed a bug for that a year or so ago... and it wasn't well received...
(13:32:51) nichoj: but apparently they changed their mind
(13:33:06) Betelgeuse: Probably with 1.5 coming to so widespread.
(13:33:12) fordfrog: and this overrides values from build.xml or just sets them as defaults?
(13:33:18) nichoj: not entirely sure
(13:33:34) nichoj: probably sets them as the default, overided by build.xml
(13:33:50) nichoj: so, that could mean we only rewrite if you're using < ant-1.7
(13:34:08) nichoj: and otherwise, update eant to pass the appropriate values
(13:34:25) Betelgeuse: nichoj: Well I wouldn't count upstream build.xmls to set the right values.
(13:34:46) nichoj: Betelgeuse: I was saying we pass the appropriate values
(13:34:56) fordfrog: and what about those tweaks building 1.4 bytecode with 1.5 source?
(13:34:56) fridrik: Betelgeuse, indeed i think they will continue to set theirs
(13:35:13) Betelgeuse: nichoj: Well if the build.xml overrides our settting.
(13:35:39) nichoj: packages that actually set a target/source are almost always correct
(13:35:51) nichoj: the problem was always when they aren't set by upstream
(13:35:59) Betelgeuse: good
(13:36:15) nichoj: fordfrog: I don't think that would be an issue
(13:36:28) nichoj: plus, I don't think that any packages really use it
(13:36:41) fordfrog: I've seen few of them.
(13:36:56) fordfrog: weeks ago
(13:37:07) nichoj: well, I haven't seen em, so my statement remains ;)
(13:37:29) nichoj: anyone have anything about ant?
(13:37:41) sanchan: no
(13:37:45) fridrik: no
(13:37:48) ali_bush: no
(13:37:56) Betelgeuse: nichoj: it sucks
(13:37:57) fordfrog: just the tweaks ;-)
(13:38:04) nichoj: Betelgeuse: heh
(13:38:34) nichoj: so, in case you've been in a cave, we have a few new minions since last time :)
(13:38:37) fordfrog: the tweaks will not work if source/target is set in build.xml and no rewrite is done
(13:39:18) nichoj: fordfrog: I think we can take a look at it more closely as we get closer to releasing it
(13:39:27) nichoj: plus, I don't expect to change over to not doing rewritting immediately
(13:39:27) fordfrog: ok, np :-)
(13:39:51) nichoj: good job so far minions, keep up the good work :-D
(13:40:26) fordfrog: should we say something? :-)
(13:40:35) nichoj: fordfrog: no one told you to speak ;)
(13:40:52) fordfrog: ok, I just couldn't stand the scilence ;-)
(13:40:57) nichoj: sure, sure :)
(13:41:10) prgrmr [n=prgrmr@bzq-88-155-107-113.red.bezeqint.net] entered the room.
(13:41:11) Betelgeuse: fordfrog: Try that in the army.
(13:41:22) nichoj: kind of related to that, but it seems that annonymous cvs/svn access is available for our main repositories
(13:41:28) fordfrog: Betelgeuse: will be shot? :-)
(13:41:36) nichoj: so, that may be useful for helping get things ready for the tree
(13:41:36) TomTom left the room (quit: No route to host).
(13:42:00) fordfrog: nichoj: do you mean qualudis?
(13:42:22) fordfrog: I tried that on svn and it didn't work
(13:42:41) Betelgeuse: fordfrog: Nope, you can now cvs checkout the live tree
(13:42:55) Betelgeuse: fordfrog: But it lags behind as much as rsync
(13:43:23) fordfrog: I was just reacting to "may be useful for helping get things ready for the tree"
(13:43:33) nichoj: the main point being, that you guys could do cvs diff, and send us the patch
(13:43:47) fridrik: ah, now i get the point
(13:43:49) Betelgeuse: Well do the diff more easily.
(13:44:32) nichoj: also could do cvs add for version bumps, and send those as diffs as well
(13:44:42) nichoj: obviously wouldn't be able to commit, but it sure could help us
(13:45:19) nichoj: this kind of thing, making it easier to get changes into the main tree, is on the agenda later, so we'll get to that in a bit
(13:45:35) fordfrog: ok, so how we can get the access?
(13:45:51) nichoj: details were announced on gentoo-dev mailing list
(13:46:00) nichoj: we can get to the details later I think :)
(13:46:07) fordfrog: ok :-)
(13:46:34) nichoj: last announcement was Betelgeuse's baby... we have a non-bin azureus in good enough shape that it was stabilized on x86 :-D
(13:47:05) Betelgeuse: But others are still having problems.
(13:47:07) nichoj: Betelgeuse: was just thinking about that, maybe could package.mask -bin on x86, and as other archs have their source version stabilized
(13:47:11) nichoj: ppc notably, iirc
(13:47:19) wltjr: problems I wonder why :)
(13:47:27) nichoj: wltjr: quiet you :)
(13:47:31) Betelgeuse: nichoj: Well I would like to do a package move
(13:47:36) nichoj: Betelgeuse: ah
(13:47:40) Betelgeuse: nichoj: But needs other arches stable first.
(13:48:08) Betelgeuse: nichoj: Of course, we could add the binary version to net-p2p/azureus as revision bumps.
(13:48:18) Betelgeuse: nichoj: That would not break anything for ppc/amd64.
(13:48:26) nichoj: true
(13:49:04) nichoj: I think that does it for 'announcements' we had on the agenda
(13:49:10) nichoj: anyone have anything else?
(13:49:48) sanchan: no
(13:49:54) ali_bush: no
(13:50:03) fordfrog: no
(13:50:31) wltjr: ls -l
(13:50:39) wltjr: opps
(13:50:43) sanchan: :-)
(13:51:11) nichoj: alrighty then
(13:51:38) nichoj: well, now that the new system is stablized, it doesn't mean our work is done :)
(13:51:40) nichoj: far from it
(13:51:47) wltjr: die java-experimental die
(13:52:16) nichoj: we still have a little under 200 packages that still haven't been migrated
(13:52:18) wltjr: at some point likely need to converge mig and exp overlays
(13:52:24) nichoj: yep
(13:52:28) nichoj: I'm getting there :)
(13:52:43) nichoj: conversely, there's probably ~ 150 or so package which have been migrated
(13:52:49) nichoj: that we should get stabilized
(13:53:13) wltjr: the not migrated packages, are these in tree or in overlay or combo?
(13:53:32) nichoj: to help track that, we should probably look into doing a similar script / reports to show what is migrated, without a stabled migrated version
(13:53:35) nichoj: main tree
(13:54:02) nichoj: the heavy lifting is done by some of the scripts in https://overlays.gentoo.org/svn/proj/java/scripts/
(13:54:16) nichoj: find-unported.py is the one that generates the reports
(13:55:00) nichoj: anyone interested in munging around with trying to script that up?
(13:55:58) ***nichoj hears the sound of crickets chirping
(13:56:20) fridrik: what are thinking about? automatic migration?
(13:56:26) nichoj: no, hardly
(13:56:30) fridrik: :)
(13:56:33) nichoj: I meant scripting up reports
(13:56:41) wltjr: so we know what we need to work on
(13:56:44) wltjr: to do lists, etc
(13:56:45) nichoj: exactly
(13:57:10) wltjr: in brief, list of packages that need migration, list of migrated, etc
(13:57:20) fridrik: that means run find-unported once a day, and put it on te wiki?
(13:57:24) wltjr: er, list of migrated unstable
(13:57:28) nichoj: fridrik: that is already done
(13:57:33) nichoj: http://dev.gentoo.org/~nelchael/java-generation-2/not-migrated-current
(13:57:39) nichoj: http://dev.gentoo.org/~nelchael/java-generation-2/progress.png
(13:57:52) nichoj: the new thing I'd like to see done, is to find migrated, but not stable
(13:58:16) wltjr: just filed 3 stabilization bugs on some ;)
(13:58:25) nichoj: just saw that :)
(13:59:10) nichoj: somewhat related to this... is we need an advocate for our stable packages
(13:59:32) nichoj: personally, I always run ~arch where I use java
(13:59:44) nichoj: I think some of you out there do the same
(13:59:50) fridrik: +1
(13:59:52) wltjr: well I filed the bugs because I needed the stuff on arch production machines
(14:00:02) nichoj: so arch sometimes doesn't the attention it needs
(14:00:10) sanchan: I use x86, ~x86 and ~amd64 testing everything
(14:00:10) nichoj: wltjr: ah, cool
(14:00:33) wltjr: I just don't have a non ~amd64 system, but will be upgrading my production tomcat server to amd64 in the next month or so
(14:00:39) fordfrog: I use ~x86
(14:00:54) Betelgeuse: I only use ~x86. I do have many x86 available though.
(14:00:56) wltjr: as for a amd64 desktop, likely far off short of a client getting one :)
(14:01:09) ali_bush: I use amd64 but keyword nearly everything java
(14:01:10) SwifT [n=Sven@dD5E06F7D.access.telenet.be] entered the room.
(14:01:38) nichoj: my main point being... don't forget the stable users :)
(14:01:59) wltjr: yes, and most stable users won't get near an overlay
(14:02:04) nichoj: yep
(14:02:12) wltjr: much less ~arch keyword stuff
(14:02:40) Betelgeuse: nichoj: I think we should have version bumping policy that says to file a stabilization bug every time you do a version bump for the older version if it does not have bugs and 30 days is up.
(14:02:51) nichoj: Betelgeuse: great idea
(14:02:58) wltjr: I was just wondering about that, I agree as well
(14:03:33) nichoj: hopefully there will be > 30 days between bumps, or stabilziation may never happen :)
(14:03:54) sanchan: Betelgeuse: it should be general policy, not java only :-)
(14:04:11) Betelgeuse: sanchan: Well the general policy actually is that ;D
(14:04:20) wltjr: so for example with itext, 1.4.5 has been in ~arch for >30 days, I just bumped it to 1.4.6, so which should I stabilize ?
(14:04:24) nichoj: not on any documentation I've seen
(14:04:25) Betelgeuse: sanchan: In general to file stabilization bugs after 30 days.
(14:04:45) fridrik: think this point is related to more effective overlays
(14:04:48) Betelgeuse: sanchan: Just forcing people to look at old versions here.
(14:04:54) nichoj: wltjr: how long was 1.4.5 in the tree?
(14:05:04) wltjr: nichoj: sep 27th
(14:05:22) wltjr: nichoj: > 30 days
(14:05:23) sanchan: Betelgeuse: ok :-)
(14:05:24) nichoj: problem is that now that there's a newer version in ~arch, people using ~arch wouldn't get it, and hence wouldn't be tested
(14:05:52) nichoj: wltjr: well, 1.4.5 then, since you, as you said, just bumped 1.4.6 :)
(14:06:17) fordfrog: how can one recall 30 days passed for a package he touched some time ago?
(14:06:25) wltjr: nichoj: ok and in 30 1.4.6, they are just minor bumps, so likely just bug fixes, not any new features or etc
(14:06:28) nichoj: fordfrog: changelogs
(14:06:54) fordfrog: hm, so I must do, no system tells me that?
(14:06:59) fridrik: can we split the overlays, creating an "awating the 30 days" one and from there file stabilization bugs?
(14:07:16) nichoj: overlays don't qualify for stabilization
(14:07:21) nichoj: they'd need to be in the main tree
(14:07:37) fridrik: no, but they can help us understanding wha twe think could go to the main tree
(14:07:42) nichoj: fridrik: yep
(14:07:44) wltjr: overlays really should be for stuff no in tree, awaiting to go in
(14:07:50) nichoj: again, something that is on the agenda :)
(14:07:53) wltjr: s/stuff no/stuff not
(14:08:17) fridrik: indeed, probably i'm skipping some points but i think we could set up a common way of doing that
(14:08:26) nichoj: very much so
(14:08:51) fridrik: like having unstable and stable overlays and once a package goes on our stable overlay, await 30 days
(14:08:53) nichoj: does anyone have anything else about migration and stabilization stuff? before moving on to this new topic?
(14:09:11) wltjr: nichoj: yes, what about badly migrated packages?
(14:09:18) nichoj: wltjr: meaning?
(14:09:45) wltjr: nichoj: like jaybird was partially migrated, from the looks it seemed like an early migration, was not using eant, and etc, just inheriting the gen 2 stuff
(14:09:51) nichoj: ah
(14:10:14) wltjr: nichoj: might need to script up something to check for that, beyond just gen2 stuff
(14:10:24) nichoj: another topic I had, QA :)
(14:10:28) wltjr: np
(14:10:30) wltjr: sry
(14:10:32) nichoj: sure
(14:10:46) nichoj: but I'd say, unless it is doing things in such a way as they break, obviously they should be fixed
(14:11:12) nichoj: if its stuff like using ant instead of eant, that isn't likely to break
(14:11:45) nichoj: like, if you want to stabilize the ant version, that is probably fine, and fixing can wait till a revbump happens
(14:12:45) wltjr left the room (quit: Remote closed the connection).
(14:13:00) nichoj: well, that's one way of tabling the subject :)
(14:13:03) jeeves: [New Bug] https://bugs.gentoo.org/154826 nor, P2, All, wltjr@gentoo.org->java@gentoo.org, NEW, pending, dev-java/itext-1.4.5 stabilization request
(14:13:14) nichoj: we're about an hour in now
(14:13:24) nichoj: shall we take a few minute recess to stretch, or continue on?
(14:13:24) wltjr [n=wltjr@gentoo/developer/wltjr] entered the room.
(14:13:25) mode (+o wltjr ) by ChanServ
(14:13:40) wltjr: segfault :(
(14:14:04) nichoj: wltjr: 14:13:14) nichoj: we're about an hour in now (14:13:24) nichoj: shall we take a few minute recess to stretch, or continue on?
(14:14:23) fridrik: i have np. continue or stop
(14:14:24) wltjr: move forward, if I stop might not return :)
(14:14:31) nichoj: heh
(14:14:31) sanchan: nichoj: continue on
(14:14:34) fordfrog: continue :-)
(14:14:48) nichoj: alright, onwards ho
(14:14:49) wltjr: nichoj: never give up momentum once built up
(14:15:32) wltjr: staffing time huh
(14:15:37) nichoj: yep
(14:16:12) nichoj: we have our own personal recruiter now, the honorable Betelgeuse
(14:16:36) wltjr: any minions ready and willing to step up?
(14:16:44) sanchan: Long life to Betelgeuse!
(14:16:45) nichoj: so he can grill our new recruits on the particulars of java in addition to the normal stuff :)
(14:16:56) wltjr: nichoj: Betelgeuse: sanchan: we need to see about making a java quiz ASAP I would assume
(14:17:00) nichoj: yep
(14:17:11) nichoj: that's the one thing I'd like to do before bringing on fresh blood
(14:17:15) nichoj: finish I suppose
(14:17:31) nichoj: I've been saying that for a while now though... sorry bout being a slacker
(14:17:41) wltjr: time frame? let's commit to getting that thing done, I would assume most final review or etc to be between nichoj and betelgeuse
(14:18:04) wltjr: less some like karltk have a comment, but they have been outside for a while, so the rest is just question contributions
(14:18:11) nichoj: I'll look at it tonight
(14:18:18) nichoj: someone can flail me tomorrow if I don't ;)
(14:18:28) ***wltjr prepares some spit
(14:18:42) nichoj: I said flail, not spit
(14:19:34) wltjr: I can hit you with a stick if you prefer that, but spit does less physical damage, more mental ;)
(14:19:44) nichoj: I suppose
(14:20:06) wltjr: I take the silence as minions are happy being such :(
(14:20:34) fordfrog: well, moving to being dev means less work done and more study
(14:20:43) ***wltjr spits on all minions not wanting or willing to step up :), but does appreciate your efforts
(14:21:26) fordfrog: I don't recall the whole process to become a dev. Could someone refresh?
(14:21:27) wltjr: being a dev is the only true way to get things done, really contribute, and make a noticeable difference for end users
(14:21:32) fridrik: wltjr, it's a matter of time. I currently prefer to focus on something in particular instead of being an official dev and squash bugs
(14:21:48) nichoj: the general process is such:
(14:21:54) Betelgeuse: Even if the java quiz is not ready, those willing to become devs could start working on the traditional quizes.
(14:21:57) wltjr: fridrik: yes, but over time you will see outside contributions end up requiring a devs time to make a reality
(14:21:58) nichoj: start contributing
(14:22:00) fridrik: wltjr, underline: "currently"
(14:22:10) fridrik: wltjr, i see
(14:22:13) nichoj: be asked to become a developer
(14:22:28) nichoj: be mentored by a current dev
(14:22:30) wltjr: fridrik: it's part of the reason I became a developer, because I was just bogging down nichoj with my needs
(14:22:31) nichoj: begin taking quizes
(14:22:58) nichoj: collaborate with mentor to correct/improve/learn the answers to the quiz
(14:22:58) wltjr: keep contributing and sticking around :)
(14:23:08) nichoj: eventually, you submit the quizes
(14:23:24) nichoj: then a recruiter will go over the quiz, and have an irc meeting with you to elaborate
(14:23:26) nichoj: grill you, etc
(14:23:35) fordfrog: nice :-)
(14:23:53) ali_bush: lovely :)
(14:23:55) nichoj: assuming you pass, then you are a developer, and cvs access, gentoo email address, follow
(14:24:12) nichoj: then obviously, the real work starts :)
(14:24:12) fridrik: yum a new dev is coming. i can smell it...
(14:24:18) Betelgeuse: And über secret -core access.
(14:24:30) wltjr: but then your work makes a real difference as well
(14:24:48) sanchan: and dev forum...
(14:25:24) Betelgeuse: sanchan: Never looked at that.
(14:25:26) nichoj: one thing we in particular are looking for, is that you are going to stick around
(14:25:46) sanchan: Betelgeuse: not much to see.
(14:25:58) nichoj: because mentoring does take time (for the mentor), and it's annoying to mentor someone and then they either wander into obscurity, or onto another project in gentoo
(14:26:01) wltjr: nichoj: and be accountable
(14:26:20) nichoj: of course
(14:26:29) Betelgeuse: nichoj: Well another project in Gentoo is not as bad as MIA entirely.
(14:27:19) fordfrog: ok, what is the mentoring phase about? preparation for quizes?
(14:27:35) nichoj: Betelgeuse: true, but if they abandon java entirely...
(14:27:41) nichoj: fordfrog: yep, and learning the ropes
(14:27:48) wltjr: fordfrog: something along the lines of what you are doing now
(14:27:54) sanchan: fordfrog: yes
(14:28:06) nichoj: if you ask me, the quizes are really just a smoke screen
(14:28:08) nichoj: er
(14:28:11) nichoj: smoke test
(14:28:27) fordfrog: was just thinking about what phase I am at :-)
(14:28:41) Betelgeuse: fordfrog: pre-quiz
(14:28:46) nichoj: as in, if you are to the point where you are being asked to join, then the quiz should be really easy for you
(14:28:46) wltjr: fordfrog: but pairing up a bit more so you have a mentor to work with, either nichoj or betelgeuse, most likely nichoj, so the process in a sense has begun, short of the quiz aspect or anything official
(14:29:39) Betelgeuse: Doing the quiz also shows some level of committement as some people never get it finished.
(14:29:54) wltjr: those damn things
(14:30:02) nichoj: Betelgeuse: ah, I'm sure you have some stories since becoming a recruiter :)
(14:30:13) ali_bush: so is there an order to the quizes?
(14:30:17) wltjr: the technical aspects are bad, but you do learn about aspects of gentoo outside of just technical ebuild stuff
(14:30:28) wltjr: s/are bad/aren't bad
(14:30:40) nichoj: ali_bush: you could feasibly work on them all concurrently
(14:30:56) fordfrog: ok, so it's "just" about taking the quizes in our case?
(14:30:57) nichoj: there is an order though for submitting, which I don't recall off hand
(14:31:10) wltjr: the one before the other
(14:31:25) wltjr: I think that's more of a mentoring call, since the one is supposed to be done at end of mentor, what ever that means
(14:31:32) nichoj: right
(14:31:34) wltjr: since there is not official mentor processor period
(14:31:49) wltjr: s/processor/process or
(14:31:53) fordfrog: http://www.gentoo.org/proj/en/devrel/quiz/
(14:32:04) fordfrog: + java quiz
(14:32:10) wltjr: basically
(14:32:15) Betelgeuse: nichoj: ebuild quiz is supposed to be done first, but I can do them both at the same time
(14:32:21) wltjr: I found the first to be more of a pain than the second
(14:32:29) nichoj: fordfrog: well, to an extent. we still have to invite you to join
(14:32:36) Betelgeuse: nichoj: Usually people get the ebuild quiz finished first so I just review that then to save time.
(14:32:51) fordfrog: nichoj: sure :-)
(14:33:01) wltjr: as you complete the quizzes you submit to mentor and maybe cc other devs for review, before final submission to recruiter
(14:33:16) nichoj: fordfrog, ali_bush, fridrik: you guys have any other questions about recruitment?
(14:33:24) fridrik: no
(14:33:29) fordfrog: it's clear
(14:33:35) wltjr: so the quiz review process can be fun, and a bit of back and forth as the quizzes, answers and understanding all gets dialed in
(14:33:55) Betelgeuse: And the process of a devs lifetime is tracked in a bug.
(14:33:56) ali_bush: no, im sweet
(14:34:14) wltjr: when quizzes are submitted to a recruiter its a reflection not only of you, but on your mentor as well
(14:34:40) nichoj: I think we have a decent pipeline for staffing needs in the work right now
(14:35:01) nichoj: but we can't forget about bringing others on as contributors either
(14:35:29) nichoj: so, if we see people consistently contributing to ml, irc, and bugzie... just let me know, and we can see about getting them overlay access
(14:35:44) wltjr: always have to be stirring the batter, while buns cook in the oven
(14:36:06) nichoj: and for the record, project leads are the ones that have to request access to overlays.g.o
(14:36:47) nichoj: I'm usually around though, so it shouldn't be a problem
(14:37:15) karltk: (back)
(14:37:21) karltk: (sorry I had to dash off)
(14:37:40) nichoj: karltk: welcome back. I'm sure you have a bit of scrollback now :)
(14:37:47) wltjr: however, not now, but we might want to discuss the leadership aspect, I have nothing wrong with nichoj, but he became our leader sorta by defacto, would hate to see that happen again, if we lost nichoj for what ever reason
(14:38:48) nichoj: wltjr: good point
(14:39:24) nichoj: it may be worthwhile gathering other contact info, for the event where someone isn't available via irc, or gentoo email
(14:39:25) wltjr: nichoj: I have not looked for it, but are there any like terms, etc to project leadership? if you get burned out, maybe betelgeuse would want to step up or etc? just was not sure if you actually wanted that or the responsibility, kinda seem thrust upon you, and don't want you to get burned out over it, thankfully you were there or java on gentoo would be SOL
(14:39:56) nichoj: wltjr: there are other 'leads', ie co-lead, strategic lead, etc
(14:40:01) nichoj: not sure what they actually mean :)
(14:40:02) wltjr: nichoj: something to think about, maybe discuss next meeting
(14:40:05) nichoj: yep
(14:40:16) wltjr: nichoj: sure, just a backup plan or etc
(14:40:23) Betelgeuse: Every project can pretty much decide by themselves on how they run things.
(14:40:30) wltjr: nichoj: otherwise we need to see about gentoo funds for some secret service peeps for you :)
(14:40:41) nichoj: heh
(14:40:52) wltjr: well let's try to avoid the ground huh :)
(14:41:56) nichoj: alright, so where are we on the agenda
(14:41:58) wltjr: nichoj: QA time
(14:42:01) nichoj: yep
(14:42:53) sanchan: well, before merge time issues
(14:43:10) karltk: nichoj: reading through it.
(14:43:10) sanchan: I think we need an unpack check
(14:43:23) nichoj: sanchan: what do you mean by that?
(14:43:43) pombred1 [n=pombreda@c-71-198-188-62.hsd1.ca.comcast.net] entered the room.
(14:43:48) sanchan: on system VM. If the system VM is a JRE WM, we need to tell to the user he have to set a JDK VM
(14:43:59) karltk: the difference between co-lead, operational lead and strategic lead are pretty established by now, I think.
(14:44:02) nichoj: sanchan: that's not needed
(14:44:10) nichoj: since system vm isn't used for merging
(14:44:18) nichoj: that's been one of the goals of the new system
(14:44:30) karltk: co-lead means a co-ruler, one that shares the throne practically equally -- it's up to the project to decide what that really means.
(14:44:38) sanchan: see bug #153750
(14:44:39) jeeves: sanchan: https://bugs.gentoo.org/153750 nor, P2, All, sawk.ita@gmail.com->sanchan@gentoo.org, RESOLVED, INVALID, dev-libs/beecrypt-4.1.2-r1 failed
(14:44:56) nichoj: sanchan: I was just telling Betelgeuse that it should be reopened
(14:45:02) nichoj: since, as I said, system vm isn't used for building
(14:45:05) sanchan: it's not a java only package
(14:45:11) wltjr: karltk: cool, we just need to establish some fall backs, as we ran the chance of a nasty void, when you stepped down
(14:45:15) karltk: strategic lead is the guy (or girl) with the vision, who plots the bigger lines and helps shepherd the project as a whole. the operational lead is down in the trenches, making the day-to-day decisions and actually making sure that things really get done.
(14:45:20) nichoj: sanchan: poing being?
(14:45:22) nichoj: er
(14:45:24) nichoj: point being
(14:45:33) karltk: the difference between op and strategic lead is also fluid -- strategic lead people are of course allowed to do good hacking!
(14:45:45) Betelgeuse: nichoj: Well it doesn't use you eclasses.
(14:45:50) Betelgeuse: s/you/our/
(14:46:05) nichoj: well, that's a bit of a different issue :)
(14:46:07) karltk: wltjr: well, the change may have come a bit sudden to the masses, but we've been quite aware of it coming for over a year:)
(14:47:09) karltk: wltjr: originally, I wanted to hand over the throne to axxo, but he left elsewhere. my next choice was nichoj, but he needed to attain some war scars before getting my (and the other Gentoo developers') approval (which he did with flying colours, I might add)
(14:47:21) wltjr: karltk: I did not have much fore sight on it at the time, I was trying to stay up on things, seemed like axxo bailed, and then a few months later we lost you
(14:47:42) wltjr: karltk: ah so that must have gone down right before I started lurking around and etc
(14:48:07) pombreda left the room (quit: Read error: 148 (No route to host)).
(14:48:11) Betelgeuse: wltjr: Actually the process starter around the time I joined.
(14:48:23) wltjr: Betelgeuse: likely we need to figure out a title for you :) despite being away you will be back sooner than later, and are more active than some not away
(14:48:29) nichoj: so one check we'd want, which can't really be at merge time... would be that if there's USE=java, we'd want to be using java eclasses
(14:48:45) karltk: wltjr: yeah. it's been a while in the coming. but in the end, I think we can say that the team survived the extremely dry season this winter -- we're a lot more devs now than we were just 6 months ago.
(14:48:59) nichoj: because our eclasses can't check that if they aren't being inherited :)
(14:49:31) sanchan: nichoj: maybe a good check to do, more again if it can be done also by repoman
(14:49:42) nichoj: yep
(14:49:52) wltjr: nichoj: what does USE=java mean? I wanted to mention/introduce a new potential use flag jni, it think in some cases where java is used we can use jni instead
(14:49:52) nichoj: or maybe qualudis and/or pkgcore-check
(14:50:37) wltjr: in brief, jni to a java package means non java code being compiled, jni on a non-java package, means native code being compiled
(14:51:42) nichoj: added to the agenda
(14:51:52) nichoj: shall we finish up QA type stuff?
(14:52:14) wltjr: nichoj: yes, that was just sorta on that front as well
(14:52:26) nichoj: tangently maybe
(14:52:36) sanchan: yes
(14:52:37) Betelgeuse: nichoj: In general Gentoo should have a tool that does checks on already installed stuff.
(14:52:53) Betelgeuse: nichoj: Then we could see if jars/class files are installed and check the eclasses used.
(14:53:08) karltk: it seems that the general concesus wrt qa is that we need tools for it, and we need to figure out a good strategy for which toolkit (qualudis, pkgcore-check, repoman) to base our efforts on.
(14:53:18) nichoj: oh, were any of you around for that nasty bug with the fellow and java-1.5-fixer ?
(14:53:27) Betelgeuse: nope
(14:53:35) nichoj: where, xerces jars were around and the package.env were there
(14:53:38) nichoj: but it wasn't 'installed'
(14:53:45) karltk: Betelgeuse: the qa story in gentoo has always been very weak, because we have a culture of "disposable scripting"
(14:53:48) Betelgeuse: karltk: As always anyone agrees that we need it, but no code.
(14:54:03) nichoj: so, qfile on the package wouldn't list associate it with a package, so 1.5-fixer wouldn't try to rebuild it
(14:54:18) nichoj: but java-config -p xerces-2 worked fine, because the package.env file was there
(14:54:35) Betelgeuse: nichoj: Well borked systems, are borked systems.
(14:54:39) wltjr: nichoj: maybe something happened to the portage cache and it is not aware of what's installed
(14:54:54) karltk: I think the best way out of this rut is to summon a qa champion, and let him run with the project. Provide sufficient incentive for him to keep going for a while terms of feedback, cookies and virtual hugs.
(14:55:11) nichoj: wltjr: I think it was more a matter of the files being modified, and when it got unmerged, it didn't remove files with different mtime
(14:55:43) nichoj: Betelgeuse: true
(14:55:55) nichoj: but maybe java-config shouldn't be able to use files that aren't really 'installed' ?
(14:56:05) nichoj: or that portage doesn't think is installed
(14:56:27) Betelgeuse: karltk: At some point I thinking about howto write a modular QA checker.
(14:56:47) Betelgeuse: karltk: If it was made pkg manager independet they could all use the checks.
(14:57:07) Betelgeuse: karltk: And make the api work with c++/python/ruby whatever to make your checks in.
(14:57:26) nichoj: Betelgeuse: interesting idea
(14:57:38) karltk: Betelgeuse: the tradeoff there being that if it becomes too modular and general, there is little reason for people to use it -- it doesn't offer enough of a timesaver.
(14:57:38) nichoj: in reality, only repoman isn't modular, pcheck and qualudis are afaik
(14:58:15) sanchan: qualudis isn't in portage
(14:58:18) karltk: btw guys, what would the checking rules look like?
(14:58:20) Betelgeuse: sanchan: it is
(14:58:30) nichoj: sanchan: paludis is
(14:58:32) nichoj: which provides it
(14:58:34) Betelgeuse: sanchan: USE="qa" emerge paludis
(14:58:49) nichoj: karltk: what do you mean?
(14:58:52) Betelgeuse: karltk: You mean what to check for java?
(14:59:03) sanchan: Betelgeuse: I can't find it, ebuild name ?
(14:59:39) fordfrog: sanchan: USE="qa" emerge paludis
(14:59:41) karltk: well, what is it exactly that we want to check? what kinds of questions do we want the checker to answer for us?
(15:00:18) karltk: is it about the integrity of an installed ebuild? about the code quality/style adherence of a specific ebuild? about potential security issues in or shell scripts?
(15:00:24) karltk: (all of the above?)
(15:00:36) Betelgeuse: karltk: two first
(15:01:09) nichoj: the second could happen any time during development, and probably should
(15:01:20) nichoj: the first, there should probably be a qa hook to invoke checks
(15:01:21) karltk: and do we want to write these checks in python? in ruby? in c++?
(15:01:40) karltk: and: are these static or dynamic checks?
(15:02:23) nichoj: checks should probably be easy and quick to implment, so probably an interpreted language is preferred
(15:02:38) wltjr: java
(15:02:43) nichoj: groovy :-D
(15:03:01) nichoj: but seriously, I'd imagine python and ruby
(15:03:02) SwifT left the room (quit: "leaving").
(15:03:14) nichoj: as far as static vs. dynamic, I think both would be desirable
(15:03:29) nichoj: although, what exactly would you mean by dynamic?
(15:03:36) ali_bush: how about java and jruby
(15:03:51) karltk: for ebuilds, dynamic checks would be done as the ebuild is run through portage.
(15:04:17) nichoj: yeah, I think they would be good to have, but trickier to implement
(15:04:18) karltk: i.e., pre/post hooks on src_install could check the validity of stuff in ${D} -- to catch bugs during the dev cycle
(15:04:33) nichoj: I could imagine there being pre/post/around hooks for every function :)
(15:04:55) karltk: also, java-config could be extended to run QA hooks in a qa mode that does thorough checking of the state of the vm you switch too, etc.
(15:05:19) karltk: does this need to work with portage?
(15:05:40) nichoj: considering portage is 'official' package manager, I would say so
(15:05:48) nichoj: although, I don't know how willing portage team would be to add this :)
(15:06:21) nichoj: I was talking with them about something similar, and someone commented that portage would become more of a hook manager than anything else....
(15:06:21) Betelgeuse: Well we can always write a QA checker using bashrc
(15:06:36) nichoj: true
(15:06:48) nichoj: although, we can't overwrite the phases we hook to from the eclasses....
(15:07:00) fordfrog: an ebuild editor with online checking would be great ;-)
(15:07:16) fridrik: about hooks, what aboaut comparing the produced jars to the binary ones?
(15:07:16) Betelgeuse: nichoj: zmedico said at one point that arbitrary hook support would be coming at some point
(15:07:17) nichoj: benny`work was poking around that idea a while back, using eclipse
(15:07:36) karltk: so has zx and myself
(15:07:46) nichoj: fridrik: interesting idea
(15:07:50) karltk: I think there's enough skill to do it.
(15:07:51) fridrik: i was missing some files packaging myfaces. i was lucky to find the missing files
(15:07:54) Betelgeuse: fridrik: apicheck can be used to do that
(15:08:13) nichoj: Betelgeuse: I think it's more for missing properties/resources
(15:08:22) Betelgeuse: nichoj: ah yes
(15:08:22) fridrik: yes
(15:08:30) Betelgeuse: nichoj: They cause nasty buggers.
(15:08:37) nichoj: oh yes
(15:08:38) fridrik: indeed
(15:08:42) karltk: afaict, then, going with pkgcore-check or repoman is better, because those are closer to portage itself -- writing a bunch of ruby checks and tying them into future versions of portage may be tricky.
(15:08:57) nichoj: but ruby is so shiny :)
(15:09:12) nichoj: there are ruby bindings for paludis iirc
(15:09:17) karltk: it would seem that we need pretty decent apis for querying the package database, ebuild script contents, package contents, etc.
(15:09:44) karltk: nichoj: yes, but how do we know that paludis will remain portage-compatible a year down the road?
(15:10:07) karltk: nichoj: i.e., that it can actually be used to diagnose problems in our official ebuilds that must and should work with portage?
(15:11:06) nichoj: valid concerns
(15:11:07) karltk: paludis seems better engineered than portage, I admit, but given the track record of its primary maintainer wrt cooperation, I'd not recommend it.
(15:11:26) nichoj: how do we know portage is portage compatible in year? ie its still the official package manager
(15:11:28) karltk: and _we_ should certainly not be taking up its maintenance when that guy quites.
(15:11:32) karltk: nichoj: lol
(15:11:40) nichoj: :)
(15:11:50) karltk: whatever package manager that replaces portage must start out as portage compatible
(15:12:06) Betelgeuse: like qualudis?
(15:12:11) karltk: and we'll just be very vocal and say that if they break the apis, they'll break all of java.
(15:12:23) Betelgeuse: And nobody cares
(15:12:27) nichoj: sigh
(15:12:39) karltk: we'll end up having to maintaing something in the end anyway.
(15:13:01) karltk: the questions is which is the lesser of all the evils. perhaps rolling our own entirely in a shiny language like ruby really _is_ the best?
(15:13:09) Betelgeuse: Well modifieng the checks to work with something should not be much a problem.
(15:13:24) karltk: (tho, for some inexplicable reason, I'm getting increasingly attracted to js4)
(15:13:39) nichoj: would basically want to encapsulate the packagemanager from the checks
(15:13:58) karltk: nichoj: yeah. that was the entire idea of gentoolkit in the first place. provide an api over the package manager.
(15:14:10) karltk: nichoj: (the gentoolkit library -- not the tool collection)
(15:14:15) nichoj: ah
(15:14:26) nichoj: could have backends for each of the package managers...
(15:14:45) karltk: yeah. but unless we have a guy working almost fulltime on this, it ain't gonna materialize
(15:15:00) nichoj: should have added a 'feasibly' there
(15:15:03) nichoj: agreed
(15:15:19) karltk: it's a huge job. and a vitally important one.
(15:15:48) nichoj: it should concern everyone, not just us though
(15:15:51) karltk: we may be able to offset any initial investment by recruiting other projects and herds to use it later.
(15:15:54) nichoj: but of course, the more chefs you have in the kitchen...
(15:16:11) karltk: yup. but this has been an unfilled gap ever since I first hacked up lintool (which preceeded repoman)
(15:17:00) karltk: my current recommendation: identify the champion, i.e. the guy who get's a kick out of this problem, and is willing to let that be his task in gentoo for the next year or two.
(15:17:32) karltk: personally, I think it's a fascinating project, but I'm all spent for now.
(15:18:57) nichoj: a single person could easily work fulltime and more on this...
(15:19:05) Betelgeuse: karltk: I would envision it being a GSOC project.
(15:19:20) Betelgeuse: karltk: Could actually do it next summer ;D
(15:19:33) karltk: Betelgeuse: yeah, that's a great idea.
(15:19:40) karltk: Betelgeuse: gsoc could actually make this happen
(15:20:56) hesshess left the room (quit: Read error: 60 (Operation timed out)).
(15:22:14) nichoj: well, we certainly have some ideas for QA :)
(15:22:55) karltk: yeah. no question about that.
(15:22:57) Betelgeuse: nichoj: Well I think QA stuff can be left to later. It's not like we have time to code much atm.
(15:23:04) nichoj: shall we move on, or does the horse need more beating?
(15:23:25) karltk: It's dead, Jim.
(15:23:29) Betelgeuse: nichoj: I think we should be opening new dev bugs today, do you agree?
(15:23:32) sanchan: move on
(15:23:38) Betelgeuse: nichoj: Getting a bit back on the agenda but.
(15:23:42) nichoj: Betelgeuse: we can talk about that after ;)
(15:23:50) Betelgeuse: sure
(15:23:57) nichoj: next item... builds which use autodetection of JDK
(15:24:03) nichoj: ie and that build different things based on it
(15:24:06) ali_bush: mmmm
(15:24:08) karltk: ugh!
(15:24:15) nichoj: I know wltjr in particular was running into this, with jdbc packages
(15:24:20) wltjr: well some things need to
(15:24:21) karltk: those krazy cats!
(15:24:29) wltjr: jaybird does this, and it's not so much for source but for features
(15:24:35) ali_bush: ugh! -> jboss
(15:24:59) nichoj: the fun part is that different things check in different ways...
(15:25:12) nichoj: one common way is to detect if a particular artbitrary class is available...
(15:25:16) euronaut left the room (quit: Remote closed the connection).
(15:26:27) fridrik: wltjr, how have you solved it?
(15:26:36) nichoj: my initial thought is to have something like USE="java6 java5" etc
(15:26:46) nichoj: could get out of control easily though
(15:26:51) nichoj: and the deps would be annoying
(15:27:36) nichoj: DEPEND=" java6? (>=virtual/jdk-1.6) !java6? ( java5? (=virtual/jdk-1.5*) !java5? (=virtual/jdk-1.4*))
(15:27:48) sanchan: maybe something like WANT_JAVA=version is better
(15:27:48) sanchan: or something eselect based
(15:27:58) wltjr: I haven't, caster made an effort to fix source/target 1.4 on 2.0.1, but that is very bad, since that makes it a version 2 driver, instead of a version 3 if built with a 1.5 jdk
(15:28:15) nichoj: sanchan: the builds wouldn't be reliably reproducable though
(15:28:25) wltjr: somethings like jaybird MUST be source/target for the same version
(15:28:49) nichoj: wltjr: I'm fairly sure all the jdbc packages will be similar
(15:28:55) wltjr: yes, they should all be the same
(15:29:09) wltjr: 1.5 = jdbc 3.0, 1.6 will be 4.0 and so on
(15:29:15) nichoj: yep
(15:29:18) wltjr: 1.4 I believe is 2
(15:29:42) sanchan: slotting the builds depending on jdk and using eselect to switching?
(15:29:59) wltjr: I would imagine more than one jdbc driver, is capable of building different versions out of the same sourcecs
(15:30:12) nichoj: sanchan: aieee
(15:30:29) wltjr: and with regard to jdbc drivers, version != type, I believe we are naming them based on type atm not version
(15:30:52) nichoj: ok... let's backtrack for a second
(15:30:59) nichoj: I think there are two main scenarios
(15:31:16) nichoj: first is the one with jdbc, where what is built is drastically different based on the jdk version used
(15:31:46) nichoj: the other is when a package has optional features for each jdk version, ie might have annotations for 1.5+
(15:32:28) robilad left the room (quit: Read error: 60 (Operation timed out)).
(15:33:08) nichoj: I think the USE flag idea I mentioned would be sufficent for the second scenario
(15:33:20) nichoj: not entirely sure it would for jdbc stuff though
(15:33:35) Betelgeuse: How about just using switching and building many jars?
(15:33:45) fridrik: wrt the first, create and slot different ebuild? jaybird-java5, jaybird-java4
(15:33:52) fridrik: Betelgeuse, yeah
(15:33:54) Betelgeuse: then during runtime use selected vm to select the jar.
(15:34:16) fordfrog: I'm looking in portage and we have jdbc2-postgresql and jdbc3-postgresql so couldn't we use this scheme?
(15:34:19) wltjr: if we were to do that, we would slot based on jdbc version the package would build, but not sure I like that, since basically you have the same ebuild, duplicated
(15:34:32) sanchan: Betelgeuse: what if I installa a JVM after I've emerged the package?
(15:34:47) sanchan: installa/install
(15:34:50) Betelgeuse: sanchan: Well you would obviously need use only the versions you DEPEND on
(15:34:50) wltjr: IMHO the current state of jdbc drivers is fubarred, so we should not really look at past or present
(15:35:10) wltjr: I believe those jdbc2-3 means type, not version
(15:35:25) wltjr: and you can have a version 1,2,3,4 type 2 driver or type 3 driver
(15:35:35) wltjr: version != type
(15:35:54) fordfrog: but if I understand correctly, this is related to jdk version used
(15:35:57) nichoj: so clarify, version is the jdbc version, ie 2.0, 3.0, 4.0
(15:36:02) nichoj: er, so to clarify
(15:36:05) wltjr: fordfrog: it's both
(15:36:19) wltjr: you can't have different source/targets for a jdbc driver, it will not produce the intended results
(15:36:51) nichoj: type refers to the type, ie is it using native protocol of db, using natively built driver, using pure java driver, etc
(15:37:12) wltjr: drivers are going to be more features and the spec level they support/implement rather than a source dep
(15:37:17) wltjr: nichoj: correct
(15:37:38) nichoj: I think I had liked the idea of different packages, ie jdbc<version>-<vendor>-type<type>
(15:37:43) wltjr: there are only 4 types, and I am not sure that will ever change
(15:38:02) wltjr: nichoj: well version I am not sure should be part of the packages name
(15:38:07) nichoj: although, type may be overkill... plus redudent ebuilds
(15:38:19) nichoj: maybe use flags for each type?
(15:38:19) wltjr: correct
(15:38:24) wltjr: really depends on source
(15:38:38) wltjr: for jaybird, one source can build any version/type you need
(15:38:42) nichoj: and switch vms in the middle of the build to build the right things
(15:38:50) wltjr: so one powerful, flexible ebuild could do it all
(15:39:11) wltjr: nichoj: not really, it will switch source code based on jdk used
(15:39:32) fordfrog: nichoj: if useflags are used then depending packages would have to check whether the package has that flag turned on, wouldn't it?
(15:39:38) wltjr: nichoj: partly for syntax/source purposes, but mainly for differences of jdbc spec implementation
(15:39:45) nichoj: fordfrog: not many things woudl depend directly on a driver
(15:39:54) wltjr: I would assume by default a package builds support for all types
(15:39:58) nichoj: wltjr: right
(15:40:15) wltjr: with the jni flag for the type that requires native code
(15:40:21) nichoj: one problem may be that source/builds/etc wildly vary from vendor to vendor
(15:40:46) wltjr: nichoj: true, and in that case the package name should reflect the jdbc type, if there are different sources for different types
(15:40:55) fridrik: what about producing all the possible jars from one ebuild?
(15:41:04) nichoj: fridrik: that's what was suggested
(15:41:10) fridrik: ah sorry
(15:41:10) wltjr: I would imagine most will have the same sources for different jdbc versions
(15:41:20) nichoj: but, like I said, maybe not all vendors could produce the jars from the same build...
(15:41:35) wltjr: nichoj: yes, that would be a type thing, not version
(15:42:06) wltjr: nichoj: I am saying if like a jdbc driver has different sources for different types, it's likely those sources can build that type to various jdbc versions based on jdk
(15:42:30) wltjr: nichoj: instead of not only have different sources per type, but different sources per jdbc version
(15:42:48) nichoj: karltk, Betelgeuse: you guys have any thoughts?
(15:43:09) wltjr: I have not looked at many others, I would need to, but I would imagine they would ship the least amount of sources possible, and re-use when applicable
(15:43:43) fridrik: nichoj, what when i run java-config -p jdbc-jaybird? i think i'll have all the jars i've installed, and that's no good
(15:43:54) karltk: nichoj: hmmm
(15:44:02) nichoj: just to get our bearings, we're about 2 1/2 hours in, with a few agenda items left
(15:44:28) nichoj: fridrik: I don't follow
(15:44:29) robilad [n=topic@dslb-084-058-252-017.pools.arcor-ip.net] entered the room.
(15:44:32) karltk: wltjr: problem with only one ebuild is that you can only install it once.
(15:44:33) nichoj: java-config -p would show what jars are installed
(15:44:52) karltk: wltjr: if somebody needs to have multiple versions installed at the same time, do we have a problem?
(15:44:55) wltjr: ok, postgresql has the same sources building various versions, 1,2, 2EE, and 3
(15:45:02) karltk: wltjr: s/versions/variants/
(15:45:30) fridrik: yeah, but if I install all the possible jars with one ebuild, i'll have a list of jars withe the same packages and classes. could this break when an ebuild DEPENDs on it?
(15:45:34) wltjr: karltk: that's pretty rare for the need to have multiple versions, maybe the need to reverse to an older jdbc version or etc
(15:45:54) nichoj: fridrik: things would likely need to depend on a particular jar they'd need
(15:45:56) fridrik: i'm not sure though
(15:46:01) karltk: wltjr: forget versions, that was a mistake on my part. I am more thinking of variants.
(15:46:06) nichoj: you have to consider too, that these drivers are special in a sense
(15:46:13) wltjr: not sure if this helps for others
(15:46:16) wltjr: http://jdbc.postgresql.org/download.html
(15:46:18) karltk: wltjr: i.e., multiple sets of USE flags.
(15:46:21) wltjr: they got a nice little chart at the bottom there
(15:46:43) ali_bush: how about having multiple package.env files for a single ebuild
(15:46:53) nichoj: that could work
(15:46:56) wltjr: karltk: really the only thing I could see one would want optional is any native stuff, jni flag, the rest can be built all into one
(15:47:11) nichoj: ali_bush: you had brought that up before, of having more than one package.env per package, and java-config would be none the wiser
(15:47:13) karltk: wltjr: okay.
(15:47:27) karltk: my feeling is that we should try a megaebuild first.
(15:47:38) karltk: easier to maintain one codebase than multiple.
(15:47:49) fordfrog: wltjr: will you provide both 1.4 and 1.5 bytecode for tomcat to satisfy eclipse-sdk and at the same time run tomcat as 1.5?
(15:48:22) nichoj: fordfrog: a little off topic at the moment
(15:48:46) wltjr: karltk: at least jaybird and postgresql are building different versions via the same sources
(15:48:48) fordfrog: nichoj: not sure, this is also multiple bytecodes for single package
(15:49:06) wltjr: fordfrog: this is more about feature than bytecode
(15:49:11) nichoj: right
(15:49:15) fordfrog: ok
(15:49:34) wltjr: this could be all 1.4 code, coded to implement 1.5 jdbc 3.0 features
(15:49:58) PerformanceBoy [n=kameli@adsl-82-141-123-69.kotinet.com] entered the room.
(15:49:58) nichoj: with this topic, I don't think we've ever been able come to some decision about how to proceed
(15:50:00) wltjr: I believe the postresql driver is type 3 only
(15:50:21) wltjr: nichoj: we might need to differ and be the first thing discussed at next meeting
(15:50:47) nichoj: I think we may want to try some of the ideas out, and see where they go
(15:50:56) nichoj: because then, at least we have something to compare to
(15:51:06) wltjr: on that note, before we all bail, might need to add to the agenda, or etc us having routine meetings or etc at regular intervals, monthly, bi-monthly etc
(15:51:24) wltjr: nichoj: yes, and research on the various drivers, what types they build, what versions they support etc
(15:51:41) nichoj: wltjr: considering this is your baby, may come down to you :)
(15:51:42) wltjr: how they go about the build process to produce jdbc versions based on jdk etc
(15:52:00) wltjr: likely, I will see about making time for it, dbs are were I live and make my $$
(15:52:18) wltjr: mainly Firebird :)
(15:52:50) wltjr: nichoj: if I can't get to it sooner, will at least compile a list/chart sometime in december
(15:52:51) nichoj: alright, so how about we shelve this. and wltjr can poke at an initial take on this
(15:52:57) wltjr: agreed
(15:53:20) nichoj: h'okay
(15:53:47) nichoj: how about we talk about our overlays and our interactions with the minions to get their work into portage?
(15:54:16) wltjr: do we want bugs filed when an ebuild is ready to go into portage?
(15:54:41) nichoj: I think the policy I had said at one point was to file a bug if its in the overlay
(15:54:57) wltjr: nichoj: when it's first added to overlay?
(15:55:09) nichoj: http://overlays.gentoo.org/proj/java/wiki/Commiter_Guidelines
(15:55:30) nichoj: wltjr: I think that would be for the best
(15:55:37) wltjr: agreed
(15:55:44) karltk: sounds good to me
(15:56:08) nichoj: so, ebuilds in overlays need a bug filed by contributors working on them, if they aren't already
(15:56:13) nichoj: InOverlay keyword needs to be added
(15:56:14) wltjr: and then just use the bug for updates and etc including when it's ready to go into tree
(15:56:25) nichoj: from there, I think we can use the Status Whiteboard for status
(15:56:37) wltjr: and bug will be closed out once put into tre
(15:56:52) nichoj: ie InitialImport, NeedsReview, ReadyForPortage, etc
(15:57:01) nichoj: that way, at least we can query for stuff
(15:57:02) wltjr: perfect
(15:57:23) nichoj: fordfrog, fridrik, ali_bush: how does that sound?
(15:57:30) fordfrog: good :-)
(15:57:32) ali_bush: great :)
(15:57:35) fridrik: i think something is missing
(15:57:57) wltjr: brb, nature callin
(15:58:01) nichoj: fridrik: like?
(15:58:06) fridrik: what about work in progress revbumps? i do not want ppl upgrading
(15:58:12) nichoj: InProgress :)
(15:58:33) fridrik: yeah, i'm talking me you and the other that has the migrated overlay in their portdir
(15:58:41) fridrik: talking about
(15:58:50) nichoj: not sure I follow
(15:59:16) fridrik: imaging i'm working on eclipse
(15:59:38) Betelgeuse: I would say that we should have separate overlays for sandbox and production stuff.
(15:59:45) fridrik: and I don't want you to upgrade when you run emerge. i'm still working on it
(15:59:49) fridrik: Betelgeuse, exactly
(15:59:50) nichoj: ah, yes, that idea came up
(16:00:00) fordfrog: fridrik: you can clear KEYWORDS before you commit or hard-mask the package
(16:00:06) nichoj: so maybe, java-overlay, and java-experimental-overlay
(16:00:09) karltk: Betelgeuse: that was one of the features of our old overlay that I liked a lot
(16:00:15) nichoj: yes, package.mask'ing would be a good practice too
(16:00:17) fridrik: fordfrog, sure, that's a solution
(16:00:33) Betelgeuse: Yeah, I have been using -* keywords
(16:00:43) Betelgeuse: That works too.
(16:00:57) nichoj: -* is considered a 'dumb' way of preventing people from installing
(16:00:59) wltjr: I like the idea of separate overlays, but I also think we should keep overlays to a min
(16:01:00) fridrik: the aim here is alsa to promote the use of the "stable experimental" overlay by casual testers
(16:01:03) sanchan: Time to leave the meeting for me
(16:01:04) nichoj: although, I think that's in a different context
(16:01:06) ali_bush left the room (quit: Remote closed the connection).
(16:01:48) nichoj: I think I do like the 'ready for portage' overlay idea, and the 'its actually experimental' idea
(16:02:10) ***karltk starts printing the stickers
(16:02:12) ali_bush [n=chatzill@203-109-237-126.bliink.ihug.co.nz] entered the room.
(16:02:23) ali_bush: mmmm.... that was strange
(16:02:36) fridrik: i'm thinking about my coworkers atm: they know i'm involved with gentoo, and would like to promote the usage of the almost stable overlay
(16:03:04) fridrik: btw I also agree with wltjr about keeping them at the min
(16:03:09) nichoj: alright... so let me suggest we do this:
(16:03:26) sanchan: See you on monday, good work.
(16:03:29) fridrik: bye
(16:03:30) nichoj: a bug open for each ebuild/package in overlay by contributors
(16:03:35) nichoj: sanchan: later
(16:03:42) wltjr: sanchan: c ya
(16:03:43) nichoj: sanchan: should have logs / summary in a few days
(16:03:49) sanchan: nichoj: thanks
(16:03:56) sanchan: bye
(16:04:02) fordfrog: bye
(16:04:05) sanchan left the room (quit: "KVIrc 3.2.5 Anomalies http://www.kvirc.net/").
(16:04:05) nichoj: we do the InOverlay for Keywords
(16:04:25) nichoj: and use InProgress, NeedsReview, ReadyForPortage for the status whiteboard
(16:04:54) nichoj: then, we'll eventually have two primary overlays, java-overlay and java-experimental-overlay
(16:04:55) wltjr: can't something be locked out via svn or etc if someone is actively working on it?
(16:05:16) nichoj: ebuilds live in java-experimental-overlay until they are ReadyForPortage
(16:05:37) nichoj: wltjr: I think that's only for people committing to it, wouldn't prevent people from checking out/using
(16:06:27) wltjr: is using -* that bad for overlays?
(16:06:38) nichoj: at that point, we have a nice overlay which developers can cherry pick ebuilds to add to the tree
(16:06:54) wltjr: nichoj: you are proposing things have to start out in exp overlay, marked ready for port, then moved to java-overlay, tested and moved to portage?
(16:07:01) nichoj: yep
(16:07:21) nichoj: additionally, when ReadyForPortage, could have a cvs diff from main tree :)
(16:07:29) wltjr: nichoj: ok, but that's the outside contributor process right? we devs can do what ever -> portage if it's stable and etc
(16:07:37) nichoj: wltjr: correct
(16:07:54) wltjr: perfect me likey
(16:08:00) nichoj: although, it may be encouraged to work in experimental first
(16:08:07) nichoj: then move to main tree when its ready
(16:08:13) fordfrog: I suppose dumb bumps could go to java-overlay directly, right?
(16:08:31) nichoj: feasibly, like if there's a minor version bump
(16:08:35) nichoj: ie 1.4.5 to 1.4.6
(16:08:43) fordfrog: ok
(16:08:56) fordfrog: related to overlays, I'd vote for using package name in log message so it is clear what the work in description was made on.
(16:08:58) nichoj: essentially, if it's in the same slot, should be fine
(16:09:06) nichoj: good point
(16:09:16) nichoj: although, even better would be using echangelog :)
(16:09:26) wltjr: updating the bug reports all along, so others know what's going on with the overlays, beyond just svn up and poking around
(16:09:27) nichoj: with a commit script
(16:09:36) fridrik: sunrise-commit does it all
(16:10:02) fordfrog: I like to have a fast overview doing just svn log and not dig what files have been changed to find out the modified package.
(16:10:04) nichoj: still haven't looked at it
(16:10:12) wltjr: I 100% agree, echanglog should be used, and also if it's a new package, create a metadata.xml and get a long description and herd tag going at min
(16:10:19) nichoj: fordfrog: that is what ChangeLog would be good for
(16:10:28) fordfrog: ah, great :-)
(16:11:06) fordfrog: where does echangelog come from?
(16:11:11) nichoj: gentoolkit-dev I think
(16:11:22) nichoj: so, it sounds like we have some good ideas for how to proceed
(16:11:26) wltjr: that will help minions get used to the dev process and etc
(16:11:30) nichoj: I will update the Committer guidelines
(16:11:36) fridrik: nice
(16:11:43) wltjr: nichoj: repoman can be used on overlays right?
(16:11:52) wltjr: also in the dev toolkit
(16:11:56) nichoj: ali_bush, fridrik, fordfrog: can you guys start going through your stuff? make sure bug is filed, with InOverlay, etc
(16:12:04) ali_bush: ok
(16:12:06) fridrik: k
(16:12:07) fordfrog: ok
(16:12:07) nichoj: wltjr: yeah. repoman is part of portage actually
(16:12:19) wltjr: nichoj: ah ok ;)
(16:12:52) nichoj: one thing I'd like done before adding the second overlay is this:
(16:12:58) nichoj: finish migrating java-experimental :)
(16:13:03) nichoj: anyone want to sign up for that one?
(16:13:20) nichoj: I'd give priority to things that are depended on from java-migrated-overlay if there are any
(16:13:23) wltjr: yes, java-migration must be converged with experimental before we create java-overlay
(16:13:43) wltjr: nichoj: I think there is a good deal of stale stuff in there
(16:13:44) fordfrog: we all must do I think :-)
(16:14:02) fridrik: agree with all
(16:14:03) nichoj: and if there are any problem packages that haven't been touched and having been used, can consider dropping them
(16:14:22) wltjr: yeah and we can dig them up if need be later
fordfrog fridrik
fordfrog fridrik
(16:15:09) robilad left the room (quit: Read error: 60 (Operation timed out)).
(16:15:13) nichoj: fordfrog: probably, I was just hoping of getting out of doing the work ;)
(16:15:14) fordfrog: is echangelog svn aware?
(16:15:18) nichoj: not really
(16:15:25) nichoj: I think there's a modified version from sunrise that is
(16:15:30) fordfrog: ah
(16:15:34) nichoj: i for the life of me, don't know why it hasn't been merged
(16:15:45) wltjr: I am dropping tomcat from java-exp, 5.5.9 is not needed for nb anymore, and I am not interested in 3.x or 4.x
(16:15:52) nichoj: word
(16:16:19) nichoj: alright... on to next item..
(16:16:25) nichoj: these last few ones I added recently
(16:16:36) nichoj: so, I'm thinking the project page could use some updating / clean up
(16:16:43) wltjr: face lift? no collagen plz
(16:16:48) nichoj: har har
(16:17:06) nichoj: so, some things I was thinking:
(16:17:18) nichoj: maybe have a 'contributors' section to go along with developers
(16:17:47) nichoj: some things in resources could be reordered, renamed, etc
(16:17:58) nichoj: maybe have more content on the main page
(16:18:09) nichoj: I was also thinking of sub projects, ie IDE support, J2EE, etc
(16:18:16) wltjr: likely need to turn some trac/wiki etc docs into official ones?
(16:18:22) nichoj: that too
(16:18:36) wltjr: sure, a page on nb on gentoo is for sure likley, I could imagine ecplise needing one as well
(16:18:39) nichoj: and with anonymous cvs access, you guys could check out the project page and learn some guidexml ;)
(16:18:43) nichoj: mmhmm
(16:18:45) wltjr: I will not be covering that type of stuff say on tomcat page, so ;0
(16:19:01) wltjr: guidexml is the shit if you have done any web dev
(16:19:08) wltjr: I like it allot
(16:19:22) nichoj: I still prefer wikis ;)
(16:19:24) nichoj: at least for drafting
(16:19:48) nichoj: aside from that, I'm open to suggestions about improving the page
(16:20:00) wltjr: pron
(16:20:03) nichoj: so, keep that mind, and give a shout if something occurs to you
(16:20:09) nichoj: oh you dirty dog
(16:20:35) nichoj: related to this, I think some of the documentation may be out of date
(16:20:50) nichoj: developer docs in particular
(16:21:12) wltjr: bugs typically for that stuff?
(16:21:21) Betelgeuse: Should pull the developer docs automatically from eclass.
(16:21:25) Betelgeuse: For the functions that is.
(16:21:29) nichoj: Betelgeuse: yes!
(16:21:38) nichoj: we had this idea for edoc akin to javadoc :)
(16:21:58) nichoj: wltjr: if there are specific items which are wrong, then absolutely
(16:22:08) nichoj: or that are missing
(16:22:48) fridrik: ( fordfrog, check this http://www.gentoo-sunrise.org/sunrise/wiki/SunriseCommitHowTo )
(16:23:07) fordfrog: fridrik: thx :-)
(16:25:47) fridrik: nichoj, for example, the here http://www.gentoo.org/proj/en/java/java-devel.xml the doc for dojavadoc is missing
(16:25:53) nichoj: indeed
(16:25:59) fridrik: (just wanted to stop the silence)
(16:26:29) nichoj: so, if everyone could take a look at the docs later, and see if there are any incongruities between what you know to be true, and what the docs say
(16:26:35) nichoj: that is all
(16:26:40) fridrik: k
(16:26:55) nichoj: 2 last things I had wanted to talk about...
(16:27:00) nichoj: 2007.0
(16:27:09) geki_ [n=anomalie@p5488575E.dip.t-dialin.net] entered the room.
(16:27:12) nichoj: we should try to figure out what we want to be stable for then :)
(16:27:44) nichoj: I'd expect it around feburaryish, but there isn't a firm plan yet
(16:27:48) wltjr: tomcat and netbeans 5.x would be nice, and any other some what popular apps, eclipse?
(16:28:00) wltjr: maybe 6.x if time permits
(16:28:02) fridrik: wltjr, yeah! was just suggesting that
(16:28:26) wltjr: glassfish?
(16:28:28) nichoj: so two points: what we want stable in general, and what we'd want to include on live media
(16:28:33) wltjr: anyone working on that
(16:28:42) nichoj: nope
(16:28:56) wltjr: sure, I would put that down as one of the main goals/agenda for next meeting
(16:29:01) nichoj: yeah
(16:29:17) nichoj: one thing Chris had mentioned at LWE was the idea of eclipse on the livecd
(16:29:18) wltjr: which should we do monthly meetings?
(16:29:35) nichoj: as, it can be an ide for c, c++, ruby, python, and java
(16:29:37) wltjr: nichoj: is there enough room?
(16:29:39) nichoj: not to slight netbeans ;)
(16:29:44) nichoj: good point
(16:29:47) wltjr: nichoj: nb can do the same :)
(16:29:52) nichoj: lies :)
(16:29:56) wltjr: not sure about ruby or python but I would imagine
(16:30:11) nichoj: well, I know there are python and ruby plugins for eclipse :)
(16:30:11) wltjr: nichoj: most of their larger ides, studio, etc are built on nb and etc
(16:30:48) nichoj: yeah, so something to keep in mind for 2007.0... hard to plan anything in particular at the moment
(16:30:53) wltjr: they used to sell the version of nb for like fortran, and etc, more robust c/++ source, but I have coded c and c++ in nb before, I believe had some make intergration and etc
(16:31:06) nichoj: the other thing I had wanted to mention was: BUGS
(16:31:14) nichoj: please be sure to keep an eye on open bugs
(16:31:17) nichoj: and try to fix them :)
(16:31:35) nichoj: and not just work on whatever particular pet project you may have
(16:31:54) nichoj: that goes for you minions too :)
(16:32:07) fridrik: :) got it
(16:32:10) ali_bush: nichoj: I think that any open jboss bugs that dont relate to >4 should be closed as WONTFIX
(16:32:13) wltjr: you can edit your buzilla option to follow java@gentoo.org so you can see what's coming to the team
(16:32:41) nichoj: wltjr: good point
(16:32:54) nichoj: I should update the tinyurl to have a query where we are cc'd
(16:33:19) nichoj: becaue right now it is just for things assigned to java@gentoo.org, and there are quite a few others where we are just cc'd
(16:33:30) wltjr: true
(16:33:51) nichoj: 365 is my current count
(16:34:43) nichoj: ali_bush: good point
(16:35:00) nichoj: so, we do need to go through all the bugs occaisionally to see what is still applicable
(16:36:16) nichoj: so, for meetings, I think bi-monthly is working out well enough
(16:36:40) nichoj: although, they do end up running a bit long, so I'm not sure if having it monthly would help
(16:36:49) wltjr: that's my only thought
(16:37:04) fordfrog: I think 4 hours for single meeting is too much
(16:37:16) wltjr: the jni thing is more of a conceptual announcement, I am not sure if we should add it to dev docs or not?
(16:37:16) nichoj: yep
(16:37:30) nichoj: wltjr: I'd rather shelf that cuz it may take awhile ;)
(16:37:33) nichoj: fordfrog: indeed
(16:38:00) wltjr: shelf what? jni? I am likely to start using it asap, because I have issues with a few packages where it's applicable
(16:38:12) nichoj: wltjr: yes
(16:38:22) ali_bush: sorry guys but I have to run off. Will read the backtrace later.
(16:38:22) wltjr: shouldn't be much discussion behind it, just when to use it and why
(16:38:22) nichoj: I'm getting a bit spent at the moment
(16:38:34) fordfrog: ali_bush: bye
(16:38:37) nichoj: ali_bush: laters
(16:38:43) wltjr: ok no worries, but it's likely the java flag will be used more and is not clear as to it's intentions always
(16:38:54) ali_bush: cya, laters :)
(16:38:55) wltjr: so people assume they need it when they don't or etc, but either way
(16:39:09) nichoj: something to keep in mind, is that we can always use the mailing list for this type of thing :)
(16:39:11) fridrik: bye
(16:39:12) wltjr: and really is a use flag that will be widely used outside of the java herd of apps
(16:39:22) wltjr: ok no problem
(16:39:42) nichoj: alright, let's wrap this bad boy up them
(16:39:49) wltjr: done
(16:40:02) nichoj: so, I'm going to say we go with bimonthly meeting, so that'd be sometime in january
(16:40:06) wltjr: any object to nb 4.x being removed from java exp overlay
(16:40:12) nichoj: not here
(16:40:24) nichoj: ali_bush: we can talk later about jboss stuff
(16:40:50) nichoj: unless there's anything else, I'd consider this meeting adjourned :)
(16:40:55) nichoj: so, who would want to write a summary?
