[Geoserver-devel] Usefulness of the road map process

GeoServer GeoServer Developer
1

Hi all,

Lately I have come into question about just how useful the road map process is. There seems to be little success in using it as a tool to plan out releases and the project short term road map.

Issues are scheduled without discussion unless explicitly asked as part of a road map update email, issues are set priority with no discussion or agreement blocking releases, etc... In short it seems the process is not agile enough or is too restricting for the project.

So I don't plan to put any more effort into such a process if it doesn't work. I am also tired of looking like the bad guy when trying to police the policy. In a few cases it has made me look like i am trying to control what goes into GeoServer. Which is ironic because the reason the process was drafted up in the first place was to ensure that no one person or organization had such rights.

So unless someone else wants to take this on I don't plan to send any more road map update emails, or work for any sort of structure into the short term road map. Which sort of leaves us in an undefined and arbitrary state in terms of release dates. But I am sure the community will figure it out as it has in the past.

-Justin

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

2

Thanks for the effort Justin;

I did appreciate the transparency the road map updates provided. I think the biggest value was you asking developers if there were ready yet; and being able to reschedule issues to a later release (rather than have us wait around not knowing).

The number one question I get about geosever is when is 2.0 coming out (which in Australia seems to be a code word for application schema support); the second is always about feature scheduling.

Jody

On 16/09/2009, at 4:04 AM, Justin Deoliveira wrote:

Hi all,

Lately I have come into question about just how useful the road map
process is. There seems to be little success in using it as a tool to
plan out releases and the project short term road map.

Issues are scheduled without discussion unless explicitly asked as part
of a road map update email, issues are set priority with no discussion
or agreement blocking releases, etc... In short it seems the process is
not agile enough or is too restricting for the project.

So I don't plan to put any more effort into such a process if it doesn't
work. I am also tired of looking like the bad guy when trying to police
the policy. In a few cases it has made me look like i am trying to
control what goes into GeoServer. Which is ironic because the reason the
process was drafted up in the first place was to ensure that no one
person or organization had such rights.

So unless someone else wants to take this on I don't plan to send any
more road map update emails, or work for any sort of structure into the
short term road map. Which sort of leaves us in an undefined and
arbitrary state in terms of release dates. But I am sure the community
will figure it out as it has in the past.

-Justin

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Could we set up a rotation so Justin is not always the person asking questions and organising Jira to match?
Jody

On 16/09/2009, at 7:02 AM, Jody Garnett wrote:

Thanks for the effort Justin;

I did appreciate the transparency the road map updates provided. I think the biggest value was you asking developers if there were ready yet; and being able to reschedule issues to a later release (rather than have us wait around not knowing).

The number one question I get about geosever is when is 2.0 coming out (which in Australia seems to be a code word for application schema support); the second is always about feature scheduling.

Jody

On 16/09/2009, at 4:04 AM, Justin Deoliveira wrote:

Hi all,

Lately I have come into question about just how useful the road map
process is. There seems to be little success in using it as a tool to
plan out releases and the project short term road map.

Issues are scheduled without discussion unless explicitly asked as part
of a road map update email, issues are set priority with no discussion
or agreement blocking releases, etc... In short it seems the process is
not agile enough or is too restricting for the project.

So I don't plan to put any more effort into such a process if it doesn't
work. I am also tired of looking like the bad guy when trying to police
the policy. In a few cases it has made me look like i am trying to
control what goes into GeoServer. Which is ironic because the reason the
process was drafted up in the first place was to ensure that no one
person or organization had such rights.

So unless someone else wants to take this on I don't plan to send any
more road map update emails, or work for any sort of structure into the
short term road map. Which sort of leaves us in an undefined and
arbitrary state in terms of release dates. But I am sure the community
will figure it out as it has in the past.

-Justin

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

On 16/09/09 05:02, Jody Garnett wrote:

The number one question I get about geosever is when is 2.0 coming out
(which in Australia seems to be a code word for application schema
support)

Not just Australia (AuScope). There is substantial international demand including from GeosciML task group, meeting next week in Quebec:
https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/QuebecF2F2009

--
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

5

So Ben that may be our clue to help manage the release train; remember the goal of GeoServer 2.0 is a new user interface - and judging from Jira that need is now met.

So what else is needed for 2.0 to go out? That is what Justin's weekly email discussions were about ...

Jody

On 16/09/2009, at 2:06 PM, Ben Caradoc-Davies wrote:

On 16/09/09 05:02, Jody Garnett wrote:

The number one question I get about geosever is when is 2.0 coming out
(which in Australia seems to be a code word for application schema
support)

Not just Australia (AuScope). There is substantial international demand including from GeosciML task group, meeting next week in Quebec:
https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/QuebecF2F2009

--
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

6

Justin Deoliveira ha scritto:
  > So unless someone else wants to take this on I don't plan to send any

more road map update emails, or work for any sort of structure into the short term road map. Which sort of leaves us in an undefined and arbitrary state in terms of release dates. But I am sure the community will figure it out as it has in the past.

If you like I can try to take this on. But I also think I'd like to see
it done differently.

Basing all the planning just on Jira feels like micro-managing things.
I don't see a problem with a developer putting a blocker in one
week before the release if he's also up to fixing the blocker in time,
and I don't really believe we can make people adjust all of the
priorities in jira to make it become a roadmapping tool.

It also feels odd that we have to push up to critical the issues
to communicate we actually want to do them by a certain release.
An issue might be minor by its nature but one might be finding it fun
and work on it on a boring hour in the weekend.

In general I'd prefer to see some goals set in text format instead,
somewhere in a wiki page. This plays a lot better with major releases
where there is a ton of jiras going on under a small number of
wider topics and gives us an idea of what is going on without the need
to turn each point 1-1 into a jira issue.

An example of what it could look like (made up):

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

The 1.7.7 release is focused on bug fixing and minor new features.
The features worked on are url mangling overhaul and map rotation.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The 2.0-rc2 release is focused on bringing stability to the
UI and catalog and improving the mapping abilities of the
complex feature support, plus eventual speedup needed to compete
in the FOSS4G benchmarking shootout.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The following major features are being worked on but did not
find an exact scheduling for a release:
- hibernate catalog, by Simone and Emanuele
- resource/publishing split
- restconfig graduation to core
- wps module
- ...

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

Once a week we can post a summary of what happened with links
to all the jiras closed during the week (since we get no notification
about that), if any module moved location (graduations)
and a check about which jiras might be blocking an
incoming release.
Plus we invite people to improve the release
summary and to talk about what major new features are being
worked on for the future.

I think this would make the system more amenable to changes
and more interesting to whoever is reading the roadmap
page?

Cheers
Andrea

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

7

Well personally I feel this is a bit too arbitrary and will lead to problems we had before, but what we have been doing has not been getting traction so it seems like a good route to go.

Andrea Aime wrote:

Justin Deoliveira ha scritto:
  > So unless someone else wants to take this on I don't plan to send any

more road map update emails, or work for any sort of structure into the short term road map. Which sort of leaves us in an undefined and arbitrary state in terms of release dates. But I am sure the community will figure it out as it has in the past.

If you like I can try to take this on. But I also think I'd like to see
it done differently.

Basing all the planning just on Jira feels like micro-managing things.
I don't see a problem with a developer putting a blocker in one
week before the release if he's also up to fixing the blocker in time,
and I don't really believe we can make people adjust all of the
priorities in jira to make it become a roadmapping tool.

It also feels odd that we have to push up to critical the issues
to communicate we actually want to do them by a certain release.
An issue might be minor by its nature but one might be finding it fun
and work on it on a boring hour in the weekend.

In general I'd prefer to see some goals set in text format instead,
somewhere in a wiki page. This plays a lot better with major releases
where there is a ton of jiras going on under a small number of
wider topics and gives us an idea of what is going on without the need
to turn each point 1-1 into a jira issue.

An example of what it could look like (made up):

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

The 1.7.7 release is focused on bug fixing and minor new features.
The features worked on are url mangling overhaul and map rotation.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The 2.0-rc2 release is focused on bringing stability to the
UI and catalog and improving the mapping abilities of the
complex feature support, plus eventual speedup needed to compete
in the FOSS4G benchmarking shootout.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The following major features are being worked on but did not
find an exact scheduling for a release:
- hibernate catalog, by Simone and Emanuele
- resource/publishing split
- restconfig graduation to core
- wps module
- ...

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

Once a week we can post a summary of what happened with links
to all the jiras closed during the week (since we get no notification
about that), if any module moved location (graduations)
and a check about which jiras might be blocking an
incoming release.
Plus we invite people to improve the release
summary and to talk about what major new features are being
worked on for the future.

I think this would make the system more amenable to changes
and more interesting to whoever is reading the roadmap
page?

Cheers
Andrea

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

8

First of all excellent well thought out post Andrea.

I spent a good 20 mins with Jira trying to sort out

  • a what was holding up the 2.0-RC2
  • what people were working on
    And was not very successful.

I think you hit the nail on the head about using critical to manage what shows up and controls the release process.

I have used the text goals; combined with a blockers from jira to manage geotools releases in the past; But I am not sure if it was helpful to anyone other then me (http://docs.codehaus.org/display/GEOTOOLS/2.5.x). You can see that for the current release I have not updated the notes (http://docs.codehaus.org/display/GEOTOOLS/2.6.x). One thing I would like to do is start managing technical debpt on individual pages that can follow the current release page …

Back on track - I am more interested in what is going on and who needs help. One idea we have on the udig list is similar to the “what is up” section of the geoserver IRC meetings. We send out an email (mostly PSC members; but also anyone with an active project) covering the usual “scrum” questions 1) what are you up to 2) tasks on your plate 3) impediments

Could we consider this in order to cover the “what is going on” questions; as well as keeping a page of notes as you suggest.

On the same topic of communication there are a couple of pages that people visit to see what is going on and tp ask for help:

I would like recommend Axios, CampToCamp, GeoSolutions, LISAsoft, OpenGeo, Refractions, Where Group etc… are visible as part of these two pages. Chris helped me tidy up (well delete backstory from) the http://geoserver.org/display/GEOS/Roadmap+Ideas page but it is pretty useless; as nobody will ever find it. In a similar manner a single Support page could cover mailing lists and commercial support. Indeed the commercial support page also has a lot of backstory.

There is one other trick that udig has - we modified out bug tracker to show two things:

  • issues that have a patch attached
  • issues that are incomplete or need to be verified be fore a developer can work on them (or even look at them)

Finally we have a separation between “resolved” and “closed” that is very helpful. We resolve an issue when the developer has made a fix; and leave it in the resolved state (it is listed on a wiki page) for a tester to close. You asked how to involve the user community in the release process - and this is a technique we have used. Finally we do use the “in progress” state which can be useful.

Jody

PS. I also want to say I respect Justin’s call to duck out of playing release cop - it is not a very reward roll; even if it has proven very valuable.

On 16/09/2009, at 6:38 PM, Andrea Aime wrote:

Justin Deoliveira ha scritto:

So unless someone else wants to take this on I don’t plan to send any

more road map update emails, or work for any sort of structure into the

short term road map. Which sort of leaves us in an undefined and

arbitrary state in terms of release dates. But I am sure the community

will figure it out as it has in the past.

If you like I can try to take this on. But I also think I’d like to see
it done differently.

Basing all the planning just on Jira feels like micro-managing things.
I don’t see a problem with a developer putting a blocker in one
week before the release if he’s also up to fixing the blocker in time,
and I don’t really believe we can make people adjust all of the
priorities in jira to make it become a roadmapping tool.

It also feels odd that we have to push up to critical the issues
to communicate we actually want to do them by a certain release.
An issue might be minor by its nature but one might be finding it fun
and work on it on a boring hour in the weekend.

In general I’d prefer to see some goals set in text format instead,
somewhere in a wiki page. This plays a lot better with major releases
where there is a ton of jiras going on under a small number of
wider topics and gives us an idea of what is going on without the need
to turn each point 1-1 into a jira issue.

An example of what it could look like (made up):

The 1.7.7 release is focused on bug fixing and minor new features.
The features worked on are url mangling overhaul and map rotation.
Link to issues fixed so far: …
Link to issues still scheduled: …

The 2.0-rc2 release is focused on bringing stability to the
UI and catalog and improving the mapping abilities of the
complex feature support, plus eventual speedup needed to compete
in the FOSS4G benchmarking shootout.
Link to issues fixed so far: …
Link to issues still scheduled: …

The following major features are being worked on but did not
find an exact scheduling for a release:

  • hibernate catalog, by Simone and Emanuele
  • resource/publishing split
  • restconfig graduation to core
  • wps module
  • …

Once a week we can post a summary of what happened with links
to all the jiras closed during the week (since we get no notification
about that), if any module moved location (graduations)
and a check about which jiras might be blocking an
incoming release.
Plus we invite people to improve the release
summary and to talk about what major new features are being
worked on for the future.

I think this would make the system more amenable to changes
and more interesting to whoever is reading the roadmap
page?

Cheers
Andrea

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

Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

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

9

Jody Garnett ha scritto:

First of all excellent well thought out post Andrea.

Thanks. Wow, lots of feedback... quickly answering to just one bit
of it, leaving the rest for some mulling.

Back on track - I am more interested in what is going on and who needs help. One idea we have on the udig list is similar to the "what is up" section of the geoserver IRC meetings. We send out an email (mostly PSC members; but also anyone with an active project) covering the usual "scrum" questions 1) what are you up to 2) tasks on your plate 3) impediments

I like this one, would make for a very nice complement to what
I've proposed in my first mail.

Cheers
Andrea

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

10

Ciao Andrea,
I think myself that doing everything by using JIRA is a bit unmanageable.
As an instance, let's say I am looking at the code and I find a place
where I can make a minor improvement, by, let's say, adding generics,
changing a cycle order to make it faster, adding a few more check to
improve robustness: in principle I should create jira before each of
these steps, which is IMHO more a waste of time than a useful thing
since it likes raise the bar for doing maintenance clean up, which is
the kind of work what you do when you are "playing" with the codebase.

I don't see JIRA as a way to communicate between users but rather to
collect bug reports, wishes etc. from users. The way I see this
working between us would be for very small things that do not change
semantics, just proceed, make sure tests work and then send an email
to the pseudo-maintainer to make sure he is aware and happy (and of
course revert if he is not). For larger development that is not itself
JIRA-driven (which means does not respond to a user bug
report/request) I would go with a wiki page + opening a few relevant
JIRA. This way, we (as in geoserver developers) would get away from
opening too many JIRA that will be closed in 1h by ourselves, but at
the same time we will meet communication goals using the WIKI to let
know other developers and users what we are doing, and JIRA to prevent
users from reporting bugs/entering feature request that are already
part of the WIKI page goals.

There is only thing about this kind of approach that makes me raise an
eyebrow, how does this relate to the GSIP thing? There might be some
duplication there both in terms of effort for the developer as well as
in documentation vs communication. The text-only wiki page describing
the goals might easily become a cut and paste of the GSIP in this
case?

I am neutral about the idea of sending regular "what I am up to"
messages to the ml. Most part of the time, I would myself send a
message like "the same thing I was doing last week"! At the same time
I realize that this is important to let other developers know what we
are doing, but hey, we don't already do that :-)? On the other side, I
am very positive about weekly (or bi-weekly) reports about what has
been done, we could rotate and do that once per PSC memeber. The one
thing I would like add is that this should be directed more towards
users than developers, so technical things + general goals that are
trying to achieve, As a user I am more interesting in understanding,
as an instance, where we are with the hibernate catalog and with the
2.0 release than in getting some technical insights for some problems
that some of us is addressing. It might actually be an idea to have
separate communication, quick scrum-like messages on the devel list
and longer, less frequent and more informative messages on the user
list.

Last thing, I second Jody's annotation and I thank Justin myself for
the effort he has putting into managing releases so far.

Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Wed, Sep 16, 2009 at 10:38 AM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:
> So unless someone else wants to take this on I don't plan to send any

more road map update emails, or work for any sort of structure into the
short term road map. Which sort of leaves us in an undefined and
arbitrary state in terms of release dates. But I am sure the community
will figure it out as it has in the past.

If you like I can try to take this on. But I also think I'd like to see
it done differently.

Basing all the planning just on Jira feels like micro-managing things.
I don't see a problem with a developer putting a blocker in one
week before the release if he's also up to fixing the blocker in time,
and I don't really believe we can make people adjust all of the
priorities in jira to make it become a roadmapping tool.

It also feels odd that we have to push up to critical the issues
to communicate we actually want to do them by a certain release.
An issue might be minor by its nature but one might be finding it fun
and work on it on a boring hour in the weekend.

In general I'd prefer to see some goals set in text format instead,
somewhere in a wiki page. This plays a lot better with major releases
where there is a ton of jiras going on under a small number of
wider topics and gives us an idea of what is going on without the need
to turn each point 1-1 into a jira issue.

An example of what it could look like (made up):

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

The 1.7.7 release is focused on bug fixing and minor new features.
The features worked on are url mangling overhaul and map rotation.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The 2.0-rc2 release is focused on bringing stability to the
UI and catalog and improving the mapping abilities of the
complex feature support, plus eventual speedup needed to compete
in the FOSS4G benchmarking shootout.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The following major features are being worked on but did not
find an exact scheduling for a release:
- hibernate catalog, by Simone and Emanuele
- resource/publishing split
- restconfig graduation to core
- wps module
- ...

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

Once a week we can post a summary of what happened with links
to all the jiras closed during the week (since we get no notification
about that), if any module moved location (graduations)
and a check about which jiras might be blocking an
incoming release.
Plus we invite people to improve the release
summary and to talk about what major new features are being
worked on for the future.

I think this would make the system more amenable to changes
and more interesting to whoever is reading the roadmap
page?

Cheers
Andrea

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

11

Ciao Simone,

While i am not defending the process (i have given up on it) I would like to make some clarifications and corrections to your statements.

Simone Giannecchini wrote:

Ciao Andrea,
I think myself that doing everything by using JIRA is a bit unmanageable.
As an instance, let's say I am looking at the code and I find a place
where I can make a minor improvement, by, let's say, adding generics,
changing a cycle order to make it faster, adding a few more check to
improve robustness: in principle I should create jira before each of
these steps, which is IMHO more a waste of time than a useful thing
since it likes raise the bar for doing maintenance clean up, which is
the kind of work what you do when you are "playing" with the codebase.

Not sure where this is coming from. Never did the process mandate that jira be made for these types of changes, although i don't see it as a bad idea though, every change having a jira makes that change trackable which imo is just good practice.

I don't see JIRA as a way to communicate between users but rather to
collect bug reports, wishes etc. from users. The way I see this
working between us would be for very small things that do not change
semantics, just proceed, make sure tests work and then send an email
to the pseudo-maintainer to make sure he is aware and happy (and of
course revert if he is not). For larger development that is not itself
JIRA-driven (which means does not respond to a user bug
report/request) I would go with a wiki page + opening a few relevant
JIRA. This way, we (as in geoserver developers) would get away from
opening too many JIRA that will be closed in 1h by ourselves, but at
the same time we will meet communication goals using the WIKI to let
know other developers and users what we are doing, and JIRA to prevent
users from reporting bugs/entering feature request that are already
part of the WIKI page goals.

It was not intended to be a tool for users, but as a tool for developers. The aggregation of jira on the Roadmap page was the high level view, and perhaps something useful to users, but never intended for that purpose. However it fell apart when it relied on people setting priorities in a consistent way.

There is only thing about this kind of approach that makes me raise an
eyebrow, how does this relate to the GSIP thing? There might be some
duplication there both in terms of effort for the developer as well as
in documentation vs communication. The text-only wiki page describing
the goals might easily become a cut and paste of the GSIP in this
case?

I am neutral about the idea of sending regular "what I am up to"
messages to the ml. Most part of the time, I would myself send a
message like "the same thing I was doing last week"! At the same time
I realize that this is important to let other developers know what we
are doing, but hey, we don't already do that :-)? On the other side, I
am very positive about weekly (or bi-weekly) reports about what has
been done, we could rotate and do that once per PSC memeber. The one
thing I would like add is that this should be directed more towards
users than developers, so technical things + general goals that are
trying to achieve, As a user I am more interesting in understanding,
as an instance, where we are with the hibernate catalog and with the
2.0 release than in getting some technical insights for some problems
that some of us is addressing. It might actually be an idea to have
separate communication, quick scrum-like messages on the devel list
and longer, less frequent and more informative messages on the user
list.

Last thing, I second Jody's annotation and I thank Justin myself for
the effort he has putting into managing releases so far.

Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Wed, Sep 16, 2009 at 10:38 AM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:
> So unless someone else wants to take this on I don't plan to send any

more road map update emails, or work for any sort of structure into the
short term road map. Which sort of leaves us in an undefined and
arbitrary state in terms of release dates. But I am sure the community
will figure it out as it has in the past.

If you like I can try to take this on. But I also think I'd like to see
it done differently.

Basing all the planning just on Jira feels like micro-managing things.
I don't see a problem with a developer putting a blocker in one
week before the release if he's also up to fixing the blocker in time,
and I don't really believe we can make people adjust all of the
priorities in jira to make it become a roadmapping tool.

It also feels odd that we have to push up to critical the issues
to communicate we actually want to do them by a certain release.
An issue might be minor by its nature but one might be finding it fun
and work on it on a boring hour in the weekend.

In general I'd prefer to see some goals set in text format instead,
somewhere in a wiki page. This plays a lot better with major releases
where there is a ton of jiras going on under a small number of
wider topics and gives us an idea of what is going on without the need
to turn each point 1-1 into a jira issue.

An example of what it could look like (made up):

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

The 1.7.7 release is focused on bug fixing and minor new features.
The features worked on are url mangling overhaul and map rotation.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The 2.0-rc2 release is focused on bringing stability to the
UI and catalog and improving the mapping abilities of the
complex feature support, plus eventual speedup needed to compete
in the FOSS4G benchmarking shootout.
Link to issues fixed so far: ...
Link to issues still scheduled: ...

The following major features are being worked on but did not
find an exact scheduling for a release:
- hibernate catalog, by Simone and Emanuele
- resource/publishing split
- restconfig graduation to core
- wps module
- ...

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

Once a week we can post a summary of what happened with links
to all the jiras closed during the week (since we get no notification
about that), if any module moved location (graduations)
and a check about which jiras might be blocking an
incoming release.
Plus we invite people to improve the release
summary and to talk about what major new features are being
worked on for the future.

I think this would make the system more amenable to changes
and more interesting to whoever is reading the roadmap
page?

Cheers
Andrea

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

12

Justin Deoliveira ha scritto:

As an instance, let's say I am looking at the code and I find a place
where I can make a minor improvement, by, let's say, adding generics,
changing a cycle order to make it faster, adding a few more check to
improve robustness: in principle I should create jira before each of
these steps, which is IMHO more a waste of time than a useful thing
since it likes raise the bar for doing maintenance clean up, which is
the kind of work what you do when you are "playing" with the codebase.

Not sure where this is coming from. Never did the process mandate that jira be made for these types of changes, although i don't see it as a bad idea though, every change having a jira makes that change trackable which imo is just good practice.

Agreed, trackable jiras are good for at least a couple of reasons:
- changelog
- a jira can contain a discussion on to why a change was made, which
   is always good context one year later when you wonder why a change
   was made and what could break if one fiddles again with the code
That said, for really minor changes I don't think a jira provides
any benefit, and I don't remember we ever mandated one for real small things either.

Cheers
Andrea

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

13

Jody Garnett ha scritto:

There is one other trick that udig has - we modified out bug tracker to show two things:
- issues that have a patch attached
- issues that are incomplete or need to be verified be fore a developer can work on them (or even look at them)

Jody, how did you modify the jira setup?
Is it something we can do with the Jira admin powers we have at hand?
It would not seem so.

Cheers
Andrea

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

14

I have a few extra admin powers left over from the early days if you like the idea.
- enabling the extra "patch attached" flag is easy and can be done quickly (JIRA has all these fields; it just does not show them unless asked).
- the extra bug state is very similar to "WONT FIX" it just sounds a bit nicer - it is basically a please make a better bug report because we cannot help you state. I created for the uDig workflow; but now that the workflow is defined geoserver could just use it.

However a lot of the benefit comes from using "Resolved" as a step to ask testers to verify a fix; if we are looking to have a week cool down period before a release when we ask for help the using Resolved makes sense.

Cheers,
Jody

On 19/09/2009, at 2:25 AM, Andrea Aime wrote:

Jody Garnett ha scritto:

There is one other trick that udig has - we modified out bug tracker to show two things:
- issues that have a patch attached
- issues that are incomplete or need to be verified be fore a developer can work on them (or even look at them)

Jody, how did you modify the jira setup?
Is it something we can do with the Jira admin powers we have at hand?
It would not seem so.

Cheers
Andrea

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