[Geoserver-devel] Missing Documentation for Geoserver 2.0

Ben_Caradoc-Davies · August 19, 2009, 8:10am

I would like to put GEOS-3266 on the roadmap from 2.0-RC2:
http://jira.codehaus.org/browse/GEOS-3266

See the issue for details.

-------- Original Message --------
Subject: [jira] Commented: (GEOS-3266) Missing Documentation for Geoserver 2.0
Date: Wed, 19 Aug 2009 16:06:59 +0800
From: Ben Caradoc-Davies (JIRA) <jira@anonymised.com>
To: Caradoc-Davies, Ben (E&M, Kensington) <Ben.Caradoc-Davies@anonymised.com>

[ http://jira.codehaus.org/browse/GEOS-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187569#action_187569 ]

Ben Caradoc-Davies commented on GEOS-3266:
------------------------------------------

I would like to promote this issue to put it on the Roadmap for the next release. There is still a huge amount of 1.7.x user doc content that is not in trunk docs. I have not even looked at the developer docs discrepancy. It concerns me that we are at 2.0-RC1 and we are still missing many features (in that they are not documented on trunk). Users still need to read 1.7.x and trunk side-by-side.

Mike and Alyssa, the new docs you have written are excellent. They must have taken quite a while. Some of the 1.7.x docs are more textual and do not require new screenshots, just some proofing and updating. These could be delegated to the original authors or knowledgeable volunteers. We can make these subtasks.

If you agree, we could promote this issue to:
Priority: Critical
Fix version: 2.0-RC2

We need it to be Critical to block release. We need it to be fix-version on a release tag for it to appear on the radar. Fix-version on a branch will be invisible.

It is time to start hassling all module maintainers to get some better docs. I am as bad an offender as any. Good docs make a huge difference to end users. Check out the latest PostGIS docs. Inspirational levels of improvement, and better than any commercial competitor. As good as PostgreSQL. Sphinx lets us do just as well.

Documentation is not what developers like to do, so you need to crack the whip.

Missing Documentation for Geoserver 2.0
---------------------------------------

                Key: GEOS-3266
                URL: http://jira.codehaus.org/browse/GEOS-3266
            Project: GeoServer
         Issue Type: Bug
         Components: Documentation
   Affects Versions: 2.0-beta2
           Reporter: alyssa wright
           Assignee: Mike Pumphrey
            Fix For: 2.0.x

        Attachments: webadmin.zip

Documentation missing for geoserver 2.0

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Chris_Holmes1 · August 21, 2009, 3:21am

Mike and Alyssa and I just spent a good bit of time on this today. Once it's all committed I believe it's on par and indeed a bit better in some places than the 1.7.x sphinx docs. The tutorials that Christian did do not have updated screenshots. If he could get to them soon that would be great, but I think it's ok if they're not there. There is still some work to do to get more confluence content over, as it didn't all make to 1.7.x.

Have we had any blocker issues on RC1 yet? I saw the style string thing, but I personally don't think that's big enough to hold up a release. If it's just documentation changes I'd say we should try to turn RC1 in to 2.0.0. Of course give it another week to see if any true blockers get reported.

OpenGeo will be spending even more time on docs in the next couple months, getting them to super high quality. But I believe we are now as good as 1.7.0 and thus good enough for release. Let me know if there's any more content from 1.7.x that you see as needing to be ported over (or just do the port).

Chris

Ben Caradoc-Davies wrote:

I would like to put GEOS-3266 on the roadmap from 2.0-RC2:
http://jira.codehaus.org/browse/GEOS-3266

See the issue for details.

-------- Original Message --------
Subject: [jira] Commented: (GEOS-3266) Missing Documentation for Geoserver 2.0
Date: Wed, 19 Aug 2009 16:06:59 +0800
From: Ben Caradoc-Davies (JIRA) <jira@anonymised.com>
To: Caradoc-Davies, Ben (E&M, Kensington) <Ben.Caradoc-Davies@anonymised.com>

     [ http://jira.codehaus.org/browse/GEOS-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187569#action_187569 ]

Ben Caradoc-Davies commented on GEOS-3266:
------------------------------------------

I would like to promote this issue to put it on the Roadmap for the next release. There is still a huge amount of 1.7.x user doc content that is not in trunk docs. I have not even looked at the developer docs discrepancy. It concerns me that we are at 2.0-RC1 and we are still missing many features (in that they are not documented on trunk). Users still need to read 1.7.x and trunk side-by-side.

Mike and Alyssa, the new docs you have written are excellent. They must have taken quite a while. Some of the 1.7.x docs are more textual and do not require new screenshots, just some proofing and updating. These could be delegated to the original authors or knowledgeable volunteers. We can make these subtasks.

If you agree, we could promote this issue to:
Priority: Critical
Fix version: 2.0-RC2

We need it to be Critical to block release. We need it to be fix-version on a release tag for it to appear on the radar. Fix-version on a branch will be invisible.

It is time to start hassling all module maintainers to get some better docs. I am as bad an offender as any. Good docs make a huge difference to end users. Check out the latest PostGIS docs. Inspirational levels of improvement, and better than any commercial competitor. As good as PostgreSQL. Sphinx lets us do just as well.

Documentation is not what developers like to do, so you need to crack the whip.

Missing Documentation for Geoserver 2.0
---------------------------------------

                Key: GEOS-3266
                URL: http://jira.codehaus.org/browse/GEOS-3266
            Project: GeoServer
         Issue Type: Bug
         Components: Documentation
   Affects Versions: 2.0-beta2
           Reporter: alyssa wright
           Assignee: Mike Pumphrey
            Fix For: 2.0.x

        Attachments: webadmin.zip

Documentation missing for geoserver 2.0

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime3 · August 21, 2009, 6:04am

Chris Holmes ha scritto:

Mike and Alyssa and I just spent a good bit of time on this today. Once it's all committed I believe it's on par and indeed a bit better in some places than the 1.7.x sphinx docs. The tutorials that Christian did do not have updated screenshots. If he could get to them soon that would be great, but I think it's ok if they're not there. There is still some work to do to get more confluence content over, as it didn't all make to 1.7.x.

Have we had any blocker issues on RC1 yet? I saw the style string thing, but I personally don't think that's big enough to hold up a release. If it's just documentation changes I'd say we should try to turn RC1 in to 2.0.0. Of course give it another week to see if any true blockers get reported.

Yes, there are grave enough reports to warrant a RC2:
- http://jira.codehaus.org/browse/GEOS-3340
- http://jira.codehaus.org/browse/GEOS-3348
- the EPSG database upgrade, which also comes with brand new
unpacking tech (supposedly a lot better than the one before, but needs
some testing)

I also have a number of user reports to double check

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Chris_Holmes1 · August 21, 2009, 12:49pm

How can rest config be a blocker? It's an extension, not even shipped with GeoServer. It can be updated on its own.

I concede we should do an rc2. And some other issues will likely come up. But it seems weird to me something that an optional extension should be a blocker.

Of course I actually think that restconfig should be core. And the fact that it's a blocker to me indicates that others consider it about the same importance. What's the status of making it core? It'd be better if people didn't have to install it separately.

Andrea Aime wrote:

Chris Holmes ha scritto:

Mike and Alyssa and I just spent a good bit of time on this today. Once it's all committed I believe it's on par and indeed a bit better in some places than the 1.7.x sphinx docs. The tutorials that Christian did do not have updated screenshots. If he could get to them soon that would be great, but I think it's ok if they're not there. There is still some work to do to get more confluence content over, as it didn't all make to 1.7.x.

Have we had any blocker issues on RC1 yet? I saw the style string thing, but I personally don't think that's big enough to hold up a release. If it's just documentation changes I'd say we should try to turn RC1 in to 2.0.0. Of course give it another week to see if any true blockers get reported.

Yes, there are grave enough reports to warrant a RC2:
- http://jira.codehaus.org/browse/GEOS-3340
- http://jira.codehaus.org/browse/GEOS-3348
- the EPSG database upgrade, which also comes with brand new
unpacking tech (supposedly a lot better than the one before, but needs
some testing)

I also have a number of user reports to double check

Cheers
Andrea

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime3 · August 21, 2009, 12:59pm

Chris Holmes ha scritto:

How can rest config be a blocker? It's an extension, not even shipped with GeoServer. It can be updated on its own.

>

I concede we should do an rc2. And some other issues will likely come up. But it seems weird to me something that an optional extension should be a blocker.

I did not create the issue, Ben did. Since it's an easy fix I did not
care to tone down the priority.

Of course I actually think that restconfig should be core. And the fact that it's a blocker to me indicates that others consider it about the same importance. What's the status of making it core? It'd be better if people didn't have to install it separately.

Hmmm... afaik there is still quite some feedback related to
issues in the module, but then again, it also means the module
is appreciated and many people are trying to use it, and it's not
like other services are not receiving bug reports.
Test coverage wise I remember Justin reporting the coverage was
pretty high.
Sooo.. yeah, why not? I guess it's Justin call to ask about inclusion
and then the PSC will have to vote.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Ben_Caradoc-Davies · August 25, 2009, 1:59am

Andrea Aime wrote:

Chris Holmes ha scritto:

How can rest config be a blocker? It's an extension, not even shipped with GeoServer. It can be updated on its own.

[...]

I concede we should do an rc2. And some other issues will likely come up. But it seems weird to me something that an optional extension should be a blocker.

I did not create the issue, Ben did. Since it's an easy fix I did not
care to tone down the priority.

Chris, it is my practice to report all build failures as blockers (= stops development) as a first step, for everything included in a release build. restconfig is included in -PallExtensions and -Prelease. Allowing failures to persist results in developers skipping tests. In this case, it is a little harsh as the failure is on Windows only, but I think we should start treating Windows as a first-class build platform. Andrea has already got almost everything building in the win32 Hudson, and aiming for a clean win32 build makes the most of this work. I was hoping to aim high.

I am happy for the team to reclassify any build failure after giving it due consideration.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Chris_Holmes1 · August 25, 2009, 2:39am

Ben Caradoc-Davies wrote:

Andrea Aime wrote:

Chris Holmes ha scritto:

How can rest config be a blocker? It's an extension, not even shipped with GeoServer. It can be updated on its own.

[...]

I concede we should do an rc2. And some other issues will likely come up. But it seems weird to me something that an optional extension should be a blocker.

I did not create the issue, Ben did. Since it's an easy fix I did not
care to tone down the priority.

Chris, it is my practice to report all build failures as blockers (= stops development) as a first step, for everything included in a release build. restconfig is included in -PallExtensions and -Prelease. Allowing failures to persist results in developers skipping tests. In this case, it is a little harsh as the failure is on Windows only, but I think we should start treating Windows as a first-class build platform. Andrea has already got almost everything building in the win32 Hudson, and aiming for a clean win32 build makes the most of this work. I was hoping to aim high.

I am happy for the team to reclassify any build failure after giving it due consideration.

Cool. My point was actually not so much that it shouldn't be a blocker, more that rest config should be core. It's a bit weird to me that it's not, as there are a lot of people using it. But I don't think extensions not building should block a release - the release should just go out without those extensions.

Kind regards,

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Ben_Caradoc-Davies · August 25, 2009, 2:55am

Chris Holmes wrote:

My point was actually not so much that it shouldn't be a blocker, more that rest config should be core. It's a bit weird to me that it's not, as there are a lot of people using it. But I don't think extensions not building should block a release - the release should just go out without those extensions.

I prefer to think of GeoServer not as core+extensions but as those things in the release profile and those outside. Core+extensions is an architectural distinction, but the users care mostly about things we ship and things we do not ship. Sure, if we can't build an extension, we should kick it from the release profile, as you suggest. The problem is what to do if we can't build it only on some platforms.

If we lose the ability to build an extension and kick it out of the release profile, it will harm the reputation of the extension and may block uptake of the new version of GeoServer by users who depend on the extension. Not something we should do lightly.

I am not proposing anything. Just chewing the cud.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia