| 01:44:37 | markusN: | I suggest that OSGeo actually *pays* someone to update trac + SQLite to get out of the continuous problems |
| 03:40:32 | milovanderlinden: | markusN; what problems are you refering to? |
| 03:41:26 | crschmidt: | milovanderlinden: as OSGeo server load has grown -- now to 4 times what it was a year and a half ago -- performance has suffered |
| 03:41:47 | crschmidt: | It is likely that upgrading trac and sqlite would help alleviate the problems, since sqlite has an order of magnitude better performance |
| 03:42:03 | crschmidt: | but since it's a systemwide upgrade, we have to upgrade 14 trac instances at once, with a limited way of falling back if we screw up |
| 03:42:12 | crschmidt: | As a result, the upgrade has been pushed off multiple times |
| 03:42:20 | : | * milovanderlinden whistles |
| 03:51:52 | milovanderlinden: | sounds like a tough job |
| 03:52:15 | milovanderlinden: | Necessary tough |
| 03:52:20 | milovanderlinden: | +h |
| 04:33:37 | sigq: | osgeofeed: Changeset [1596]: added schedule.yml <http://trac.osgeo.org/osgeo/changeset/1596> |
| 04:33:41 | CIA-43: | osgeo: sab * r1596 /foss4g/2009/website/foss4g09_staticmatic/ ( 42 files in 25 dirs ): added schedule.yml |
| 04:47:30 | sigq: | osgeofeed: Changeset [1597]: added schedule.yml <http://trac.osgeo.org/osgeo/changeset/1597> |
| 04:48:18 | milovanderlinden: | Even CrunchBang! ( #! ) proberen. reboot.. |
| 04:48:29 | CIA-43: | osgeo: sab * r1597 /foss4g/2009/website/foss4g09_staticmatic/ ( 32 files in 21 dirs ): added schedule.yml |
| 10:37:06 | pramsey: | stick a fork in me, I'm done |
| 10:37:17 | pramsey: | incubation humor |
| 10:38:52 | : | * danmo reads three times ... laughs... but still thinks he got only half of the story |
| 10:39:01 | danmo: | : ) |
| 10:52:38 | hobu: | GeoToolkit's governance model doesn't fit OSGeo's, and OSGeo's GeoTools governance model was one of the reasons GeoToolkit forked, no? |
| 10:53:31 | crschmidt: | hobu: I think that there is an impression that the split was partly the result of the specific implementation of the model, rather than the model itself, but it certainly doesn't measure up currently, and seems like that is a key point of the fork |
| 10:56:29 | danmo: | hobu: my understanding matches what you just wrote, but I feel that I may be missing some facts to make an opinion |
| 10:58:41 | danmo: | for instance, the bit about GeoTools being driven by GeoServer development/releases got me wondering |
| 10:59:50 | danmo: | GDAL/OGR development is influenced by MapServer and even some customer's needs and that's not a bad thing... that wouldn't justify a fork... unless there is clear abuse and lack of openness to other users/projects |
| 11:01:00 | danmo: | so I wonder if the situation with GeoTools being driven by GeoServer is that bad... has anyone seen what's going on? |
| 11:02:27 | crschmidt: | danmo: I don't think that GDAL is *driven* by any one particular project. |
| 11:02:29 | crschmidt: | The needs are too varied. |
| 11:02:40 | hobu: | I think MapServer's influence on GDAL development is quite limited, especially these days. Heck, *ESRI* has the most influence over GDAL right now ; ) But GDAL's administration works because it defers to people who do instead of people who whine. |
| 11:02:48 | hobu: | I whine a lot, but nothing changes unless I do ; ) |
| 11:02:48 | danmo: | note that I wrote "influenced", not driven |
| 11:02:50 | : | * crschmidt was thinking the same thing wrt ESRI |
| 11:04:01 | crschmidt: | danmo: I've said this before: I think if anyone was interested in significantly refactoring GDAL, the only way to do it would be through a fork of the code. There are too many people with too diverse of a set of needs for GDAL to ever be significantly refactored within the current project scope |
| 11:04:13 | crschmidt: | ( howard phrases this as "GDAL 2.0 is *never going to happen*" ) |
| 11:05:21 | hobu: | maybe GeoTools/GeoToolkit reached that point |
| 11:05:37 | danmo: | Here is an uninformed opinion/guess then: maybe the same thing is happening with GeoServer's use of GeoTools: GeoServer has practical needs that prevents GeoTools from evolving in the direction that some people want |
| 11:05:48 | danmo: | ( what hobu just wrote in 6 words ) |
| 11:08:23 | hobu: | There's something to be said for one project exerting so much influence over another that it really ceases to be a separate concern. I don't know that it was the case with GeoServer/GeoTools though. In the GeoToolkit ( they should have picked a more distinct name unless they're purposely trying to muddy things ) team's eyes, it must appear so |
| 13:39:20 | sigq: | osgeofeed: Changeset [1598]: Added sponsorship/endorsement requests. <http://trac.osgeo.org/osgeo/changeset/1598> |
| 13:39:35 | CIA-43: | osgeo: camerons * r1598 /foss4g/2009/documents/sponsor/ ( 4 files ): Added sponsorship/endorsement requests. |