Okay this answered my questions; I was trying to determine if this email thread was being communication or frustrating
Looks like the answer is a bit of both: - frustrating to those working with coverages day in and day out - communication to everyone else Adrian Custer you are correct that a design document (or specification) would be a great thing to lean on. Since we all need to make a living on this one with the code we have we will need to figure out a way to work together. Sure wish I could attend that code sprint and help you guys on this one. Is using the code sprint to look at the issues around coverages out of the question? It is pretty tragic that we could not work together on the GeoServer side of things; if coverage operations are also suffering it may be time go on a branch. At issue here is several people making a living with the same code base; the combination of deadlines / communication and lack of reference document make working with GeoTools expensive for this problem. I think a lot of the frustration is basic risk management; if we can sort out a time line so that the developer community can plan around, pitch in or delay your work it would go a long way towards making people feel comfortable. Right now I have no idea of the extent of what is going on; how long it is going to take and so forth - and I have deliveries to meet. I feel particularly powerless on this one as I don't have time/resources to help; I only know I need MRSID support working on trunk :-) Is putting together a timeline something that can be done? I am treating this as a project management / planning issue rather than a technical one. I cannot afford to be scared off of trunk; and I don't want to cut a 2.5.x branch right now (even though we hit the feature set we were aiming towards). Cheers, Jody > Hi guys; this is a fascinating thread but nobody changes the subject > line ... this is just a general request to keep things sane and happy on > trunk. > And also a +1 for creating a proposal page. > > A couple of related questions: > a) the api changes that are happening; is this part of the expected long > term GeoAPI plan? (if so it would fall outside our proposal page process) > b) I noticed trunk depending on GeoAPI 2.2-SNAPSHOT; is this correct or > is there a GeoAPI 2.3-SNAPSHOT we should be using > > Martin I think you are stressed out on a deadline are you not? Can I > help set up the proposal page for you ... it will at least let me catch > up on all this email. > Jody > PS. I have some work to do on trunk so I am very interested in keeping > it real :-) > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
