[Geoserver-devel] Killing "stable" developer guide

Hi all,

Any objections to removing the “stable” developer guide link from the docs page? It is not like the user guide in that we need to maintain multiple branches of it. And actually currently the stable one is out of sync and missing some content.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Fri, Jun 17, 2011 at 3:46 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Any objections to removing the "stable" developer guide link from the docs
page? It is not like the user guide in that we need to maintain multiple
branches of it. And actually currently the stable one is out of sync and
missing some content.

Works for me. What about people really wanting to develop on 2.1.x?
Some sort of redirect to the trunk guide could be interesting.

Generally speaking there are two kinds of developers:
- those that contribute to the project. They know trunk is the only place
  where a commit must always be, unless you want to lose it at the
  next series. They don't need a "stable" developer guide
- there is the lot of developers customizing GS for their own use, which
  often stay on the stable series. These people often do not contribute
  squat to GeoServer, so we could say we don't care.... or we could make
  it easy for them to get in, hoping that someone sees the light and tries
  to actually contribute back (those that do not plan to contribute back
  anything anyways, well, they don't exist to me).

Long story short, it boils down to whether the dev guide has strong
ties to the branch (I guess it does not atm?) and whether we want
to reach out for potential new devs (though I admin the return potential
is often low).

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Yeah, this would be ideal for sure but given the resources we have in general and the resources in the past we have dedicated to making life easier for the developer rather than the user i don’t really see it happening. So as it stands now the “stable” developer guide seems more like a maintenance burden more than anything else.

On Fri, Jun 17, 2011 at 8:02 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jun 17, 2011 at 3:46 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Any objections to removing the “stable” developer guide link from the docs
page? It is not like the user guide in that we need to maintain multiple
branches of it. And actually currently the stable one is out of sync and
missing some content.

Works for me. What about people really wanting to develop on 2.1.x?
Some sort of redirect to the trunk guide could be interesting.

Generally speaking there are two kinds of developers:

  • those that contribute to the project. They know trunk is the only place
    where a commit must always be, unless you want to lose it at the
    next series. They don’t need a “stable” developer guide
  • there is the lot of developers customizing GS for their own use, which
    often stay on the stable series. These people often do not contribute
    squat to GeoServer, so we could say we don’t care… or we could make
    it easy for them to get in, hoping that someone sees the light and tries
    to actually contribute back (those that do not plan to contribute back
    anything anyways, well, they don’t exist to me).

Long story short, it boils down to whether the dev guide has strong
ties to the branch (I guess it does not atm?) and whether we want
to reach out for potential new devs (though I admin the return potential
is often low).

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

  • there is the lot of developers customizing GS for their own use, which
    often stay on the stable series. These people often do not contribute
    squat to GeoServer, so we could say we don’t care… or we could make
    it easy for them to get in, hoping that someone sees the light and tries
    to actually contribute back (those that do not plan to contribute back
    anything anyways, well, they don’t exist to me).

An advantage of switching to github is that we could document the recommended customization path as forking GeoServer in to their own repository. If they do that then we’d be able to see the changes and customizations people do and be able to encourage them to contribute back.

C

On Fri, Jun 17, 2011 at 7:51 PM, Chris Holmes <cholmes@anonymised.com> wrote:

An advantage of switching to github is that we could document the
recommended customization path as forking GeoServer in to their own
repository. If they do that then we'd be able to see the changes and
customizations people do and be able to encourage them to contribute back.

Yep. Still there are the issues about switching to git, see the recent
discussion here:

http://osgeo-org.1803224.n2.nabble.com/Community-modules-and-the-whole-development-process-td6360374.html#a6372851

Afaik the thread stopped due to lack of time to setup a synchronized
clone on git?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

I think that would be fine; is there a downloaded copy of the stable guilde (in case people want to look at the build instructions or something?).


Jody Garnett

On Friday, 17 June 2011 at 11:46 PM, Justin Deoliveira wrote:

Hi all,

Any objections to removing the “stable” developer guide link from the docs page? It is not like the user guide in that we need to maintain multiple branches of it. And actually currently the stable one is out of sync and missing some content.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


EditLive Enterprise is the world’s most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Sat, Jun 18, 2011 at 6:37 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I think that would be fine; is there a downloaded copy of the stable guilde
(in case people want to look at the build instructions or something?).

Which are going to change, right. Trunk java 6, 2.1x java 1.5

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

I am not sure this really warrants a separate branch of documentation… seems like it could be one line of the build instructions. But it seems there is pushback to removing the stable developer guide so I’ll drop the topic and hope that doc writers keep remember to keep the two in sync, a step that i myself have already missed a few times.

On Sat, Jun 18, 2011 at 2:14 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Jun 18, 2011 at 6:37 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I think that would be fine; is there a downloaded copy of the stable guilde
(in case people want to look at the build instructions or something?).

Which are going to change, right. Trunk java 6, 2.1x java 1.5

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Sat, Jun 18, 2011 at 8:10 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I am not sure this really warrants a separate branch of documentation...
seems like it could be one line of the build instructions. But it seems
there is pushback to removing the stable developer guide so I'll drop the
topic and hope that doc writers keep remember to keep the two in sync, a
step that i myself have already missed a few times.

Justin, have you tried git+cherry-pick for patch backports?
I've been using for a while, quite happy about it (a step above trying to
deal with backports in svn imho).

Rough steps to follow:
- checkout from svn with full tags and branches, with a shallow story
if you don't need it all,
  something like:
  git svn init -s --prefix=geoserver/ https://svn.codehaus.org/geoserver .
  git svn fetch -r 16050:HEAD
- at this point git branch -r show show all tags and all branches that
have had at
  least one commit between revision 16050 and HEAD (in this case,
trunk and 2.1.x)
  If a new branch is added just run git svn fetch again (this time
without revision references)
- git svn checkout -b 2-1-x branches/2.1.x
- git svn checkout master

Now you commit something on master, get its id from git log, and then
git checkout 2-1-x
git cherry-pick <id>
(often this does not generate conflicts, sometimes it does and you
have to handle them)
<build>
git svn dcommit

This makes backporting really quick. The version of git I'm using can
only do single
cherry picks, but I hear the latest can cherry-pick a range of commits.

Hope this helps

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------