2.2.RC1/2.1.1 Release
FeatureCollection/RnD Q&A
Color Brewer API Changes
Metting Times

<iant_> hi
<jgarnett> Hi Ian!
<rschulz> hello
<jdeolive> hi all
<jdeolive> jody asked me to run the meeting today, so i will start by asking for any agenda items
<jdeolive> 1) 2.2.RC1 release
<jgarnett> Thanks Justin, and yeah 2.2.RC1 is a good idea ...
<jgarnett> I should give an RnD update, but I have been sending email ...
<jgarnett> 2) RnD FeatureCollections Q&A ....
<jdeolive> good idea, 1 feeds into 2
<chorner> 3) ext/brewer (making ColorBrewer more usable)
<jdeolive> 4) meeting times
<jgarnett> I have an RnD question for after class, if people are into chatting after the meeting ...
<jdeolive> alrighty, if noone has any more items, lets kick it off and try to get out early
<jdeolive> 1) 2.2.RC1
<jgarnett> Um - Chris wanted us to release way more often, I was hoping for every six months.
<jdeolive> as i said this feeds into the rnd work that has been going on, but the jist is to get a 2.2 release out and stable, making way for some of the rnd work coming down the pipe
<jgarnett> We have had 6 RnD merges to trunk since 2.1, and uDig 1.1 is going out the door. If you guys want to do a GeoTools 2.2 release then we could be game on this end...
<Polio> hey, is there still a need / want for two branches of active devel?
<jdeolive> one stable, one experimental?
<Polio> one stable ... and a seperate branch for each experiment (like we do, but minus the experimental)
<jgarnett> we have been doing quick 2 week branches and RnD merges with some success
<iant_> definitly need a stable one
<jdeolive> i like the quick experiment branch, then merge back up
<jgarnett> 2.1.x has been a very good stable branch, has been collecting bug fixes and so on ...
<Polio> yes, agree 2.1.x has been good
<jgarnett> although some "formatting" got in the way recently of sharing bug fixes ...
<Polio> just wondering if the 2.2 equivalent (2.3) would be needed / wanted
<jgarnett> I would assume 2.3 = trunk?
<jdeolive> one of the things that wories me about 2.1.x though is that its not trunk so its too tempting to stay on it for too long
<jgarnett> Although we could just go with 2.3.x and not have a trunk
<Polio> actually was hoping stable == trunk
<Polio> and then what ever is done in a branch would either be merged on or rejected ...
<iant_> me too
<jgarnett> I think this is what we have been doing for trunk right now ...
<Polio> So, we don't need a 2.2.x stable then
<Polio> we'll just have trunk as stable?
<jgarnett> I would assume we would, if only so uDig can release a uDig 1.1.1 whe/if needed
<jdeolive> so what about rnd that makes major api changes, will they have to timed with a major release?
<jgarnett> trunk can be stable, but we still need the ability to release a patch if there is a serious problem.
<Polio> justin: well, they should represent a release ... so hopefully yes
<jgarnett> So far I have only seen one bug worth releasing as a 2.1.x patch, and even then with a documented workaround I would probably forgo it. Justin has their been any showstopper bug fixes on 2.1.x?
<Polio> jody: bumping the minor revision number on a stable branch is expected ...
<jdeolive> nope, all of them have been merged to trunk
<jgarnett> Question was the other way around, what would stop you releasing GEOS 1.3.0 from GeoTools 2.1.0
<jdeolive> well geos wont compile on trunk for one
<jgarnett> Still your point is taken Polio, tag != fork
<jdeolive> two with all the style work that has been going on it would require a lot of testing
<jgarnett> Still the other way around, does GEOS 1.3.0 codebase run on 2.1.0 release
<jdeolive> no
<jgarnett> Changes have been made on 2.1.x branch, are they mission critical - it is only for curosity - and to (I think) illustrate what Polio was asking about.
<jgarnett> Okay so back to topic 2.2.RC1 is a good idea, and 2.1.1 release is also a good idea.
<Polio> agreed
<jdeolive> agreed
<jdeolive> ok so if that is all, lets move onto 2
<jdeolive> 2) RnD FeatureCollections Q&A ....
<jdeolive> jody i beleive the floor is yours
<jgarnett> Right ... it is pretty much all put down in email and the web page on the topic
<jgarnett> I just wondered if anyone had anyquestions,
<jgarnett> I should note that this represents a small portion of the FM work branched out in September
<jgarnett> (Aka the FeatureCollection side of things, Filter and FeatureType remain on the branch)
<jdeolive> no questions?
<jgarnett> Okay if there are any questions lets take it to email ?
<jdeolive> cool, that was fast, lets move onto 3
<jdeolive> cory
<chorner> ok
<jdeolive> 3) ext/brewer (making ColorBrewer more usable)
<chorner> just a heads up... i'm adding to colorBrewer and operating on the assumption that no one is using it, so I can break things
<chorner> james make take issue with this, but we'll see
<jgarnett> um - what are you adding? I have not seen email or a web page?
<jdeolive> maybe send a quick heads up in email
<jgarnett> Or have you and james been emailing ...
<iant_> Well
<iant_> ... James might not but I might
<chorner> i'll e-mail too, just making it return useful sets of palettes
<iant_> ?
<chorner> ...merging the 3 palettes into one ColorBrewer object, rather than forcing the user to create 3 individuals ones
<jgarnett> Once again I am not sure I have the background to track what you are saying ...
<Polio> Yah, lost here too ... but sounds like something that can be done outside he existing API ...
<iant_> Sounds ok to me but I don't really know the code well enough yet - I'v e only been James for a month now
<chorner> my main change will be the creation of the colorBrewer object
<chorner> sorry... the loading of palettes
<chorner> ...I could deprecate I suppose, but i'd have a conflict with constants
<jdeolive> ok, maybe continue this one on email to flush out all the issues?
<chorner> anyways, i'm proposing a small API change, which won't require much rewriting, but it would break your code
<chorner> next?
<jgarnett> In general you don't need to worry about depricating until after it has been out in a full on release
<iant_> ok as long as you document well - the developer is off until Jan for holiday break
<jdeolive> onto 4 then
<jdeolive> 4) meeting times
<jdeolive> have the majority of people decided on times?
<Polio> I'm happy with noon ... but I'm MOST happy about the time cap
<jgarnett> Well this time seems good, we have enough people attending to vote if need doing. GEOS set up a conflict with 4 UTC, I will be around at 5 UTC if we want to try again.
<jgarnett> Yeah ditto on the time cap.
<iant_> now works best for me
<rschulz> any time is ok for me, but I cannot attend when I am at work
<jgarnett> now will work horrible for me mid Jan onward
<rschulz> I should be around during jan, but working again on a project in feb
<jgarnett> So we got too meeting times today. Lets see how the one this evening goes. I would have to say this one is on track, more due to the time cap then anything else.
<jdeolive> ok, after we see the attendance tonight we can move forward
<jdeolive> so does anyone have anything else?
<jgarnett> Nothing important for the agenda, I may ask prople a stupid naming question afterwards ...
<jdeolive> alright, well meeting over then, anyone who wants to stick around feel free
<Polio> later guys, thanks for a great meeting
<jdeolive> thanks everyone who showed up
<jdeolive> good turnout today
<jgarnett> I will just send my naming question to the list, thanks Justin
<jdeolive> alright cool, later all