From: Jesse E. <je...@re...> - 2006-02-28 18:41:26
|
Hi, I'd just like to clarify that uDig 1.1.x based on Geotools 2.2.x but making no changes to it beyond bug fixes and uDig 1.0.6 (released in December) is the last release that will use 2.1.x. The 1.0.x branch no longer sees any development. Cheers, Jesse > > > -------- Original Message -------- > Subject: [Geoserver-devel] 1.4.x and trunk > Date: Tue, 28 Feb 2006 03:27:56 -0500 > From: db...@op... > CC: geo...@li... > > > > Okay, I talked to some of the Udiggers and apparently their unstable > development branch is going to use geotools 2.2.x and they are "happy" > with it. > > The udig stable branch, as far as I know, is still based on geotools > 2.1.x (see the udig mailing list and their homepage) - just like > geoserver 1.3.x (stable). > > As far as moving to new geotools versions in the future, I'd like to > have a bit more of a conservative approach. Geotools is definitely > NOT conservative, so I think we have to be. For one thing, I don't > just want to move to the latest geotools unless its a *real* stable > branch (not just someone saying "okay, lets call what we have now 2.#, > label is "stable" so we can forget about supporting it). That means we > need geotools to think that its good, and are planning to maintain it. > Also, we shouldn't move to it until udig does too. > > So, before we move to a new geotools: > > 1. Geotools needs to say that the "new" branch is stable, good, and > recommend that all users use it (or transition to it). This should be > on their front page as the "version we recommend people use, report > bugs against, and submit patches for". > 2. We evaluate the branch and see if its "good" and if we want to move > to it. > 3. We wait (or get) udig to move to it > 4. We move to it. > > > I'm a bit concerned with 2.2.x because it wasn't really advertised as > existing. The messages about its formation are basically "we're really > gonna be stirring up the API now, we better put out 2.2 now or we'll > never be able to". It appears that the official announcement was > just a message saying, "I took the liberty of creating the 2.2.x > branch." Not exactly confidence instilling! > > > > > I am very concerned that geoserver will start following the path that > geotools has taken (add lots of "new" exciting things but don't > actually maintain what's already there). Unfortunately, this path has > caused a lot of frustration for their developers and users. So much > so that they are actually losing developers and credibility. I do not > want to see this happen to geoserver. > > I see a lot of talk about "new" exciting R&D work for geoserver, but > very little about maintaining and improving whats actually already > there. > > There's *a lot* of work to do in geoserver that does NOT include any > changes to geotools or re-architecturing geoserver. There's also a > *gigantic* amount of basic maintenance and bug fixes required in > geotools. I'm not even talking about adding any new features - just > getting the ones that are already there working well! I just want to > hear that we're actually going to be spending resources improving > things -- not just adding new things. This work isn't glamorous or > fun, but it necessary. Its doubly necessary since this is the > opposite of what's happening in geotools. We need users (potential > and current) to know that we take useablity and stability (in terms of > things working well) seriously. We need focus! > > > > But, onto the 1.4 in specifics. > > So, the main change in 1.4 is moving to geotools 2.2. But, the most > obvious one is that everything has been shuffled around and there's a > new build system. > > Here's some comments/questions: > > 0. This shuffle needs to be evaluated. Is it good? Is there still > more to do? I havent seen any discussion about it - I have no clue > whats happened. > > 1. We need to update ALL the documentation to account for this. > There's no use in having "How does a GetFeature request work?" > documentation if you get lost in the 1st step. We also need new > documentation so current developers can figure out whats going on - I > know I'm lost. > > If it isnt updated, then we have two other major problems: > > a) people who are new to geoserver will not take us at all > seriously if documentation and reality are massivily out-of-alignment. > b) by not updating existing documentation you are telling the > saints who actually write it that their efforts are in vain. It hard > enough to get people to write documentation, but impossible if you're > going to obsolute it and not correct it. > > 2. The build system is still a bit clunky. It takes me just under 10 > minutes to do a build. Under the old system it would take at most 1.5 > minutes - most of the time it would take less than 1/2 a minute. > > a) I need an easy way of being able to do a geotools build and > have geoserver restart with the new jars. Under the old system I had > a 3 line script that would (a) build geotools (b) copy the gt main jar > to the geoserver lib/ directory (for future builds) and (c) copy the > jar to the deployed server's lib/ directory. That way I could just > stop geoserver, run my script, and then restart geoserver. I'd have > the same configuration with the new jars up in less than a minute > (most of that time spent building geotools). This makes doing > geotools development (and testing) easy. I'm completely lost in the > new system. > > b) I also need a way to build a new geoserver.jar and put it > inside the deployed server. There is an ant task to do this (I think > its called "move geoserver.jar") - its only 2 lines long. This allows > me to quickly make changes to geoserver and run test them in the same > configuration. > > In fact, the only time I do a full geoserver build is when I modify > the .jsp file or deploy a new configuration (and if I did the latter > more often I'd have an ant task to just refresh the .jsps in the > deployed server). 10 minutes is *forever*. If I do that 6 times, it > means that I've wasted an entire hour. I *hate* being that > unproductive. > > 3. I'd like to hear what the raster branch people think. Its probably > going to take them a while to merge their old-and-modified-version to > the new-and-modified-and-shuffled version. > > 4. Are all the changes taking place on the current trunk in 1.4? > Who's moving changes between the stable branch and trunk? How about > moving bug fixes between 1.4 and the stable branch? > > 5. Who's doing maintance? Do they have actual time to do it? > > 6. I'd like to continue having a new stable release every 2-4 weeks. > That means releases on the stable branch, not 1.4 releases. 1.4 can > release on whatever schedule it wants - just make sure that we clearly > differenciate between the two so people dont accidently download one.. > > 7. Dont merge big changes onto trunk until they are actually *very* > good. > > > > > Geoserver has greatly improved over the last year I've been involved - > thats mostly because I concentrated on making it useable and doing all > the really boring work of fixing bugs and systematically going through > geoserver and geotools to make sure things work. And by "work" I mean > (1) they're not buggy (2) they do what they're supposed to do (3) they > are easy to use (4) there's documentation on them. I think everyone > can agree that there needs to be a lot more work done - both in > geoserver, > and certainly in geotools. I'd like to see this continue. I really > want to make sure (just to repeat myself a fourth time) that there > is a significant effort made in maintainance and improving things - > not just adding new features. From the way people are talking I dont > know if this is the same as other people's goals. Sure, its fun to add > the new stuff, but its extreamly important to make sure whats there is > improving too. We're asking people to trust their spatial data > infrastructure (including updating it) to us. > > *I* want to actually use geoserver to do a bunch of geowiki stuff - I > need a stable platform to do that. > > dave > > > > > > ---------------------------------------------------------- > This mail sent through IMP: https://webmail.limegroup.com/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Geoserver-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > |