Blog from Aug 18, 2008

0. Whats Up
1. 2.5.0 Release
2. Unsupported Module Handling

jdeolive has changed the topic to ``1) 2.5.0 release''
aaime has changed the topic to ``0) What's up 1) 2.5.0 release''
<aaime> ok, I added my topic, we're even (wink)
Eclesia has no topic to give
groldan is now known as groldan|holiday
<jdeolive> ping aaime, acuster, afabiani_ , cbriancon , Eclesia , simboss , vheurteaux
<jdeolive> hi all, meeting time, jody asked me to run
<jdeolive> anyone have any agenda items?
<afabiani_> hello
<aaime> jdeolive, what are you still doing at the keyboard?
<aaime> run! (smile)
<jdeolive> (smile)
<jdeolive> aaime: (tongue)
<jdeolive> (wink)
<jdeolive> ok, lets start
<simboss> pong
<jdeolive> 0) whats up
jdeolive is working on getting gs 1.7.0 out, requiring gt 2.5.0
aaime is reading mail and looking around after a week vacation, also getting ready to go to foss4g 2008
Eclesia playing with rendering
<simboss> hating python right now
<jdeolive> ok moving on...
<jdeolive> 1) 2.5.0 release
<--| Mediii has left #geotools ("Leaving.")
<jdeolive> not much to say here... we hope to release 2.5.0 by the end of the week
<jdeolive> jody has a few things to get out of the way for this release.... so i figure we give him a few days to do that
<aaime> I guess the crucial issue is to leave out of the downloads the unsupported modules?
<jdeolive> and tehen release toward the end of the week
<jdeolive> correct
<jdeolive> right, his proposal
<aaime> but we're ok deploying them to maven repo right?
<jdeolive> aaime: yes, i believe that is the idea
<jdeolive> leave them out of the release, but available to the other projects that need them
<aaime> I'm ok with that proposal
<jdeolive> as am i
<aaime> just
<aaime> we have to make sure the build servers build with -Dall
<aaime> like, when you make an api/behaviour change
<aaime> what are you supposed to check?
<aaime> if unsupported is out of the build
<jdeolive> or... have all build by default
<jdeolive> and have the "release profile" limit the modules
<aaime> if you can do that, it would be ideal imho
<jdeolive> agreed,
<jdeolive> i also don
<jdeolive> t see why the property all is used... rather then just directly invoking the profile
<jdeolive> its my experience that profiles work better when invoked directly... rather then relying on a property
<aaime> yeah, agreed, using the profile directly it's more direct
<jdeolive> ok... so two bits of feedback thus far?
<aaime> less troublesome
<jdeolive> 1) invoke profile directly
<jdeolive> 2) have unsupported included by default, make release filter them out
<aaime> jdeolive, afaik maven profiles are "addictive", in that they only override/add config
<aaime> so we should have a default profile that uses everything
<jdeolive> addictive = additive?
<aaime> yeah sorry
<jdeolive> (smile)
<aaime> (once you start using profiles, they get addictive as well)
<jdeolive> they can be quite addicting too though, once you start you cant stop!!!
<jdeolive> (smile)
<aaime> anyways, that's a little troublesome
<aaime> since we may have other profiles that do not have anything to do with the unsupported modules build
<aaime> and they will interefere with the eventual default profile there... bah...
<jdeolive> yeah... it seems profiles in gt are a bit of a mess at the moment
<jdeolive> pending, archive, unsupported.... now release
<jdeolive> i see trouble on the horizon as well
<aaime> ah,t hat's probably why Jody is using variables
<taichimaro> merci Eclesia
<aaime> afaik you can have two profiles activate/deactivate according to the presence of a certain system variable
<jdeolive> correct
<taichimaro> tu fais vraiment bcp de choses qui aident
<taichimaro> merci
Eclesia slaps taichimaro
<taichimaro> haha pq
<Eclesia> chutttt, meeting time
<taichimaro> (big grin)
<jdeolive> which is where they have an opportunity to trip each other up
<aaime> Meh, if we use a default profile any other profile activating will kill it thought
<aaime> Description of "activeByDefault" says: This profile will automatically be active for all builds unless another profile in the same pom is activated using one of the previously described methods.
<jdeolive> yup... which is why i like the direct profile approach, activating profiles by default should be banned imho
<aaime> which means we'll need to always build gt2 with -Pall?
jdeolive prefers getting only what he asks for
<aaime> afaik all the trouble arises from the hypothesis that's not possible to remove modules from a build using profiles, only adding them
<jdeolive> aaime: i dont think thats true
<jdeolive> you can ovveride the entire modules section can you not?
jdeolive could be wrong
<jdeolive> actually i think i am wrong
<jdeolive> sorry
<aaime> mumble, when we use profiles in gs, we have a modules section for each
<aaime> and they are additive
<jdeolive> right right
jdeolive slaps himself
<aaime> so?
<jdeolive> maybe we should have an unsupported profile then...
<jdeolive> and by default not build unsupported modules...
<aaime> right
aaime hopes that devs will remember to add the profile to build everything
<aaime> One thing that we should make clear in the proposal is that
<aaime> if you break the build with a change and the error is in an unsupported module
<aaime> the build is broken for good
<aaime> What I fear is that people will get the message "unsupported modules are none of our concern, not even build wise, anymore"
<jdeolive> correct, we should ensure that is not the case
<jdeolive> i think having the build server yell at them should do a decent job of that
<jdeolive> buut agreed
<jdeolive> we should make it clear in the proposal
<aaime> cool
<aaime> well, hopefully jgarnett will read the logs
<aaime> anything else?
<jdeolive> nope, i think thats it
<jdeolive> unless anyone else has anything?
<aaime> nope
<jdeolive> cool, lets call it a meeting then (smile)
<jdeolive> i will post the logs
<aaime> thx (smile)