[Geoserver-devel] PSC: GSIP 34 is open for vote and feedback, and also, is the PSC alive?

GeoServer GeoServer Developer
1

Hi,
over one week ago I posted a request to review/vote GSIP 34 (roadmap)
and so far nobody has answered.

"We don't need roadmap" or" "The GSIP is ill conceived" are valid answers. No answer at all is not valid.
I remind you the PSC can be disbanded if not working. From GSIP 0
(http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee)

"If there are no suitable replacements, the PSC can decide to go down in number. If the number of active PSC members drops below 5, however, then TOPP reserves the right to take back active control of the project or to pass it on to an organization that will effectively steer it. We sincerely hope that will never happen, but want a policy in place so that we avoid a zombie project, forcing someone else to eventually fork GeoServer or some such."

and also:

"If you find you cannot make meetings for a month or two, by all means step aside. Thank you so much for your time, if you want to groom a successor and then nominate them that is cool, but the nomination process still applies.

If we do not hear from you for two months we will assume you lost, send out a search party and nominate your replacement.

That is to say, status on PSC is lost if not active at all in a two month period of time. Of course you can come back on to the PSC if you become active again, but a new nomination procedure will be needed. "

If nobody is interested in GSIP 34 I'll just remove the page, no big deal.
If, on the other side, the current members of the PSC have no interest
or time to steer the project, then we have a serious problem.

Cheers
Andrea

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

2

Sorry to jump in, but this is GSIP 43, right? (I like to follow the not-too-technical GSIPs.)

http://geoserver.org/display/GEOS/GSIP+43+-+Roadmap+and+release+handling+process

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Andrea Aime wrote:

Hi,
over one week ago I posted a request to review/vote GSIP 34 (roadmap)
and so far nobody has answered.

"We don't need roadmap" or" "The GSIP is ill conceived" are valid answers. No answer at all is not valid.
I remind you the PSC can be disbanded if not working. From GSIP 0
(http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee)

"If there are no suitable replacements, the PSC can decide to go down in number. If the number of active PSC members drops below 5, however, then TOPP reserves the right to take back active control of the project or to pass it on to an organization that will effectively steer it. We sincerely hope that will never happen, but want a policy in place so that we avoid a zombie project, forcing someone else to eventually fork GeoServer or some such."

and also:

"If you find you cannot make meetings for a month or two, by all means step aside. Thank you so much for your time, if you want to groom a successor and then nominate them that is cool, but the nomination process still applies.

If we do not hear from you for two months we will assume you lost, send out a search party and nominate your replacement.

That is to say, status on PSC is lost if not active at all in a two month period of time. Of course you can come back on to the PSC if you become active again, but a new nomination procedure will be needed. "

If nobody is interested in GSIP 34 I'll just remove the page, no big deal.
If, on the other side, the current members of the PSC have no interest
or time to steer the project, then we have a serious problem.

Cheers
Andrea

3

Mike Pumphrey ha scritto:

Sorry to jump in, but this is GSIP 43, right? (I like to follow the not-too-technical GSIPs.)

Right, sorry! :-p

Cheers
Andrea

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

4

Hi

I am waiting for feedback from those more intimately involved in the
release cycle - otherwise you can have a +0 from me, based on my
ignorance of our ability to actually resource the plan.

Rob

On Fri, Nov 20, 2009 at 2:59 AM, Andrea Aime <aaime@anonymised.com> wrote:

Mike Pumphrey ha scritto:

Sorry to jump in, but this is GSIP 43, right? (I like to follow the not-too-technical GSIPs.)

Right, sorry! :-p

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Rob this about communication - not so much about the release cycle. Justin has stepped down as release manager and this represents a way forward. It is the PSC responsibility to cover planning and release procedures - so our response is needed here.

aside: In terms of the PSC responsibilities we should strike the one about attending weekly IRC meetings.

Jody

On 19/11/2009, at 8:29 PM, Rob Atkinson wrote:

Hi

I am waiting for feedback from those more intimately involved in the
release cycle - otherwise you can have a +0 from me, based on my
ignorance of our ability to actually resource the plan.

Rob

On Fri, Nov 20, 2009 at 2:59 AM, Andrea Aime <aaime@anonymised.com> wrote:

Mike Pumphrey ha scritto:

Sorry to jump in, but this is GSIP 43, right? (I like to follow the not-too-technical GSIPs.)

Right, sorry! :-p

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

Hi Andrea; as I was involved in proposing this I have not provided feedback thus far.

I am concerned about the language used to identify specific roles; in my experience "mandating" volunteers based on need does not work - still we have to try.

The roles are clear and come with associated responsibilities; what is missing is the associated stick. We need to ensure the release manager can actually schedule changes into the road map ( even if it means keeping work in branches).

One part that is missing from my intention in this write up is the idea of the "roadmap" page for a release becoming the download page for the release - it already has the high level summary of what has been done. So not only is the page "just like the download page" - it becomes the download page when the release is published.

All in all I like the direction of this proposal; especially the single page including long term roadmap items.

Jody

On 19/11/2009, at 1:04 PM, Andrea Aime wrote:

Hi,
over one week ago I posted a request to review/vote GSIP 34 (roadmap)
and so far nobody has answered.

"We don't need roadmap" or" "The GSIP is ill conceived" are valid
answers. No answer at all is not valid.
I remind you the PSC can be disbanded if not working. From GSIP 0
(http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee)

"If there are no suitable replacements, the PSC can decide to go down in
number. If the number of active PSC members drops below 5, however, then
TOPP reserves the right to take back active control of the project or to
pass it on to an organization that will effectively steer it. We
sincerely hope that will never happen, but want a policy in place so
that we avoid a zombie project, forcing someone else to eventually fork
GeoServer or some such."

and also:

"If you find you cannot make meetings for a month or two, by all means
step aside. Thank you so much for your time, if you want to groom a
successor and then nominate them that is cool, but the nomination
process still applies.

If we do not hear from you for two months we will assume you lost, send
out a search party and nominate your replacement.

That is to say, status on PSC is lost if not active at all in a two
month period of time. Of course you can come back on to the PSC if you
become active again, but a new nomination procedure will be needed. "

If nobody is interested in GSIP 34 I'll just remove the page, no big deal.
If, on the other side, the current members of the PSC have no interest
or time to steer the project, then we have a serious problem.

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

Hello all,

sorry for my delay and absence during this last period, I was very very busy … actually I’m very interested in this GSIP since we are working hard on a lot of improvements and implementation especially in the raster side. In particular we want to transform very very soon GeoServer in a real ND spatial server and improving the catalog management … so basically I give my +1 to the Roadmap and Release handling process since the proposal is very interesting and my promise to be more present … my only concern about this proposal is if the release procedure could become too much heavy and onerous.

Regards,
Alessio.

Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com

On Fri, Nov 20, 2009 at 1:48 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Andrea; as I was involved in proposing this I have not provided feedback thus far.

I am concerned about the language used to identify specific roles; in my experience “mandating” volunteers based on need does not work - still we have to try.

The roles are clear and come with associated responsibilities; what is missing is the associated stick. We need to ensure the release manager can actually schedule changes into the road map ( even if it means keeping work in branches).

One part that is missing from my intention in this write up is the idea of the “roadmap” page for a release becoming the download page for the release - it already has the high level summary of what has been done. So not only is the page “just like the download page” - it becomes the download page when the release is published.

All in all I like the direction of this proposal; especially the single page including long term roadmap items.

Jody

On 19/11/2009, at 1:04 PM, Andrea Aime wrote:

Hi,
over one week ago I posted a request to review/vote GSIP 34 (roadmap)
and so far nobody has answered.

“We don’t need roadmap” or" “The GSIP is ill conceived” are valid
answers. No answer at all is not valid.
I remind you the PSC can be disbanded if not working. From GSIP 0
(http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee)

“If there are no suitable replacements, the PSC can decide to go down in
number. If the number of active PSC members drops below 5, however, then
TOPP reserves the right to take back active control of the project or to
pass it on to an organization that will effectively steer it. We
sincerely hope that will never happen, but want a policy in place so
that we avoid a zombie project, forcing someone else to eventually fork
GeoServer or some such.”

and also:

"If you find you cannot make meetings for a month or two, by all means
step aside. Thank you so much for your time, if you want to groom a
successor and then nominate them that is cool, but the nomination
process still applies.

If we do not hear from you for two months we will assume you lost, send
out a search party and nominate your replacement.

That is to say, status on PSC is lost if not active at all in a two
month period of time. Of course you can come back on to the PSC if you
become active again, but a new nomination procedure will be needed. "

If nobody is interested in GSIP 34 I’ll just remove the page, no big deal.
If, on the other side, the current members of the PSC have no interest
or time to steer the project, then we have a serious problem.

Cheers
Andrea

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

8

Alessio Fabiani ha scritto:

Hello all,

sorry for my delay and absence during this last period, I was very very busy ... actually I'm very interested in this GSIP since we are working hard on a lot of improvements and implementation especially in the raster side. In particular we want to transform very very soon GeoServer in a real ND spatial server and improving the catalog management ... so basically I give my +1 to the Roadmap and Release handling process since the proposal is very interesting and my promise to be more present ... my only concern about this proposal is if the release procedure could become too much heavy and onerous.

What is heavy and what can be done to improve it?

Your role as a PSC member mandates you make active effort in
steering the project. This includes bringing ideas to the table.

Cheers
Andrea

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

9

Well … reading this proposal I am personally a bit scared to be a release manager, this is like another job and speaking just for me, I guess would be almost impossible to be an efficient release manager basically for lack of time reasons, even if in the near future my plan is to heavily contribute to filling up the roadmap. Moreover finding two people available for every release process seems to me not so easy … on my opinion the risk is that at the end we will have difficulties finiding reources to handle this process or just the same people will be always proposed as release managers, which is unfair of course … I have no specific ideas or proposals right now, we can speak together about this … maybe we can just slim down a bit the release process or envisage subtasking responsabilities to the people involved in the roadmap by assigning to each person the duty to follow his specific contribute.

Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com

On Fri, Nov 20, 2009 at 9:55 AM, Andrea Aime <aaime@anonymised.com1…> wrote:

Alessio Fabiani ha scritto:

Hello all,

sorry for my delay and absence during this last period, I was very very
busy … actually I’m very interested in this GSIP since we are working
hard on a lot of improvements and implementation especially in the
raster side. In particular we want to transform very very soon GeoServer
in a real ND spatial server and improving the catalog management … so
basically I give my +1 to the Roadmap and Release handling process since
the proposal is very interesting and my promise to be more present …
my only concern about this proposal is if the release procedure could
become too much heavy and onerous.

What is heavy and what can be done to improve it?

Your role as a PSC member mandates you make active effort in
steering the project. This includes bringing ideas to the table.

Cheers
Andrea

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

10

On 20/11/2009, at 7:09 AM, Alessio Fabiani wrote:

Well … reading this proposal I am personally a bit scared to be a release manager, this is like another job and speaking just for me, I guess would be almost impossible to be an efficient release manager basically for lack of time reasons, even if in the near future my plan is to heavily contribute to filling up the roadmap.

You should volunteer to be release manager - that way you are sure to accept your changes for the next release :slight_smile:

Moreover finding two people available for every release process seems to me not so easy … on my opinion the risk is that at the end we will have difficulties finiding reources to handle this process or just the same people will be always proposed as release managers, which is unfair of course …

The actual task of making the release represents a couple of days a month. The tricky part is planning now that we no longer have weekely IRC meetings. (Indeed restoring IRC meetings would be alternative?).

I have no specific ideas or proposals right now, we can speak together about this … maybe we can just slim down a bit the release process or envisage subtasking responsabilities to the people involved in the roadmap by assigning to each person the duty to follow his specific contribute.

I do not believe we can slim down the release process (and still keep quality). What we can do is be very active about testing with the community in order to place less burden on one person. Slimming down the release process is not the hard part here; with it representing two days; the hard part is asking everyone to commuicate so there are no surprises and no disappintments.

Jody

Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com

On Fri, Nov 20, 2009 at 9:55 AM, Andrea Aime <aaime@anonymised.com1…> wrote:

Alessio Fabiani ha scritto:

Hello all,

sorry for my delay and absence during this last period, I was very very
busy … actually I’m very interested in this GSIP since we are working
hard on a lot of improvements and implementation especially in the
raster side. In particular we want to transform very very soon GeoServer
in a real ND spatial server and improving the catalog management … so
basically I give my +1 to the Roadmap and Release handling process since
the proposal is very interesting and my promise to be more present …
my only concern about this proposal is if the release procedure could
become too much heavy and onerous.

What is heavy and what can be done to improve it?

Your role as a PSC member mandates you make active effort in
steering the project. This includes bringing ideas to the table.

Cheers
Andrea

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

11

Dear all,
providing some feedback.

I think that a 1 month release cycle may be too much of a burden,
especially since we have nightly builds that people can use, therefore
I would suggest to reconsider this timing.
I am +1 about doing an IRC meeting like once every month to perform
better communication between PSC/developers about the release, as well
as about the process itself and I would consider that meeting the time
to schedule new releases. I mean, saying that we should discuss about
releases once every month is ok with me, saying we should actually do
a release once a month is not ok with me. I'd like not to concentrate
too much on burocracy but rather on features and quality and I don't
want to end up spending too much resources in doing releases (I am
talking as a PSC not as GeoSolutions). Moreover this might also impact
development negatively, IMHO.
The key for me is having PSC decide when the release should be done,
still, having a tentative timeline (once every month) in place, but
the process should not be automagical but rather based on minimal
consensus. I think that this would be a good balance between the
"release eraly release often" and the fact that developers tend to do
development instead of packaging :-).
If people talk and decide it is good a time to do a release, I bet
there will be no issue in finding volunteers to actually do it; on the
other end, I would be resilient to volunteer for a release that ust
contains a few bug fixes over a previous release thas was done just
one month ago. Moreover if we think about involving, code freeze,
anouncement on the devel list, test week, etc.. I think there would a
risk for us to end up devoting a little to much resource/attentions to
the release process.

The same applies to bi-monthly releases.

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 Fri, Nov 20, 2009 at 11:59 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

On 20/11/2009, at 7:09 AM, Alessio Fabiani wrote:

Well ... reading this proposal I am personally a bit scared to be a release
manager, this is like another job and speaking just for me, I guess would be
almost impossible to be an efficient release manager basically for lack of
time reasons, even if in the near future my plan is to heavily contribute to
filling up the roadmap.

You should volunteer to be release manager - that way you are sure to accept
your changes for the next release :slight_smile:

Moreover finding two people available for every release process seems to me
not so easy ... on my opinion the risk is that at the end we will have
difficulties finiding reources to handle this process or just the same
people will be always proposed as release managers, which is unfair of
course ...

The actual task of making the release represents a couple of days a month.
The tricky part is planning now that we no longer have weekely IRC meetings.
(Indeed restoring IRC meetings would be alternative?).

I have no specific ideas or proposals right now, we can speak together about
this ... maybe we can just slim down a bit the release process or envisage
subtasking responsabilities to the people involved in the roadmap by
assigning to each person the duty to follow his specific contribute.

I do not believe we can slim down the release process (and still keep
quality). What we can do is be very active about testing with the community
in order to place less burden on one person. Slimming down the release
process is not the hard part here; with it representing two days; the hard
part is asking everyone to commuicate so there are no surprises and no
disappintments.
Jody

-------------------------------------------------------
Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
-------------------------------------------------------

On Fri, Nov 20, 2009 at 9:55 AM, Andrea Aime <aaime@anonymised.com> wrote:

Alessio Fabiani ha scritto:
> Hello all,
>
> sorry for my delay and absence during this last period, I was very very
> busy ... actually I'm very interested in this GSIP since we are working
> hard on a lot of improvements and implementation especially in the
> raster side. In particular we want to transform very very soon GeoServer
> in a real ND spatial server and improving the catalog management ... so
> basically I give my +1 to the Roadmap and Release handling process since
> the proposal is very interesting and my promise to be more present ...
> my only concern about this proposal is if the release procedure could
> become too much heavy and onerous.

What is heavy and what can be done to improve it?

Your role as a PSC member mandates you make active effort in
steering the project. This includes bringing ideas to the table.

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
http://p.sf.net/sfu/bobj-july_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

12

As a public service, I am changing the incorrect title of this thread. :wink:

I also suggest that any proposal discussion thread contain a link to the proposal, for the convenience of readers. Here is one Mike prepared earlier:

On 19/11/09 23:55, Mike Pumphrey wrote:
> Sorry to jump in, but this is GSIP 43, right? (I like to follow the not-too-technical GSIPs.)
>
> http://geoserver.org/display/GEOS/GSIP+43+-+Roadmap+and+release+handling+process
>
> Thanks,
> Mike Pumphrey
> OpenGeo - http://opengeo.org

On 23/11/09 14:25, Simone Giannecchini wrote:

Dear all,
providing some feedback.

I think that a 1 month release cycle may be too much of a burden,
especially since we have nightly builds that people can use, therefore
I would suggest to reconsider this timing.
I am +1 about doing an IRC meeting like once every month to perform
better communication between PSC/developers about the release, as well
as about the process itself and I would consider that meeting the time
to schedule new releases. I mean, saying that we should discuss about
releases once every month is ok with me, saying we should actually do
a release once a month is not ok with me. I'd like not to concentrate
too much on burocracy but rather on features and quality and I don't
want to end up spending too much resources in doing releases (I am
talking as a PSC not as GeoSolutions). Moreover this might also impact
development negatively, IMHO.
The key for me is having PSC decide when the release should be done,
still, having a tentative timeline (once every month) in place, but
the process should not be automagical but rather based on minimal
consensus. I think that this would be a good balance between the
"release eraly release often" and the fact that developers tend to do
development instead of packaging :-).
If people talk and decide it is good a time to do a release, I bet
there will be no issue in finding volunteers to actually do it; on the
other end, I would be resilient to volunteer for a release that ust
contains a few bug fixes over a previous release thas was done just
one month ago. Moreover if we think about involving, code freeze,
anouncement on the devel list, test week, etc.. I think there would a
risk for us to end up devoting a little to much resource/attentions to
the release process.

The same applies to bi-monthly releases.

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 Fri, Nov 20, 2009 at 11:59 AM, Jody Garnett<jody.garnett@anonymised.com> wrote:

On 20/11/2009, at 7:09 AM, Alessio Fabiani wrote:

Well ... reading this proposal I am personally a bit scared to be a release
manager, this is like another job and speaking just for me, I guess would be
almost impossible to be an efficient release manager basically for lack of
time reasons, even if in the near future my plan is to heavily contribute to
filling up the roadmap.

You should volunteer to be release manager - that way you are sure to accept
your changes for the next release :slight_smile:

  Moreover finding two people available for every release process seems to me
not so easy ... on my opinion the risk is that at the end we will have
difficulties finiding reources to handle this process or just the same
people will be always proposed as release managers, which is unfair of
course ...

The actual task of making the release represents a couple of days a month.
The tricky part is planning now that we no longer have weekely IRC meetings.
(Indeed restoring IRC meetings would be alternative?).

I have no specific ideas or proposals right now, we can speak together about
this ... maybe we can just slim down a bit the release process or envisage
subtasking responsabilities to the people involved in the roadmap by
assigning to each person the duty to follow his specific contribute.

I do not believe we can slim down the release process (and still keep
quality). What we can do is be very active about testing with the community
in order to place less burden on one person. Slimming down the release
process is not the hard part here; with it representing two days; the hard
part is asking everyone to commuicate so there are no surprises and no
disappintments.
Jody

-------------------------------------------------------
Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
-------------------------------------------------------

On Fri, Nov 20, 2009 at 9:55 AM, Andrea Aime<aaime@anonymised.com> wrote:

Alessio Fabiani ha scritto:

Hello all,

sorry for my delay and absence during this last period, I was very very
busy ... actually I'm very interested in this GSIP since we are working
hard on a lot of improvements and implementation especially in the
raster side. In particular we want to transform very very soon GeoServer
in a real ND spatial server and improving the catalog management ... so
basically I give my +1 to the Roadmap and Release handling process since
the proposal is very interesting and my promise to be more present ...
my only concern about this proposal is if the release procedure could
become too much heavy and onerous.

What is heavy and what can be done to improve it?

Your role as a PSC member mandates you make active effort in
steering the project. This includes bringing ideas to the table.

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
  http://p.sf.net/sfu/bobj-july_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

13

Simone Giannecchini ha scritto:

Dear all,
providing some feedback.

I think that a 1 month release cycle may be too much of a burden,
especially since we have nightly builds that people can use, therefore
I would suggest to reconsider this timing.

...

The key for me is having PSC decide when the release should be done,
still, having a tentative timeline (once every month) in place, but
the process should not be automagical but rather based on minimal
consensus. I think that this would be a good balance between the
"release eraly release often" and the fact that developers tend to do
development instead of packaging :-).
If people talk and decide it is good a time to do a release, I bet
there will be no issue in finding volunteers to actually do it; on the
other end, I would be resilient to volunteer for a release that ust
contains a few bug fixes over a previous release thas was done just
one month ago. Moreover if we think about involving, code freeze,
anouncement on the devel list, test week, etc.. I think there would a
risk for us to end up devoting a little to much resource/attentions to
the release process.

I agree on the general reasoning. In the end it's almost obvious, if there is no one interested and available to do a release, then no
release is done.
And if someone wants to push for a monthly release, well, he can,
he just has to make himself available to do the release tasks.

I've changed the GSIP to incorporate your feedback:
- removed hard references to monthly releases and worded it so that
   actual dates take into consideration available resources
- asked the release announcement to include thanks to both roadmap
   and release managers, and the companies backing them, to provide
   both with the respect and gratitude they deserve for the work done.

Cheers
Andrea

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

14

Simone Giannecchini ha scritto:

I am +1 about doing an IRC meeting like once every month to perform
better communication between PSC/developers about the release, as well
as about the process itself and I would consider that meeting the time
to schedule new releases. I mean, saying that we should discuss about
releases once every month is ok with me, saying we should actually do
a release once a month is not ok with me. I'd like not to concentrate
too much on burocracy but rather on features and quality and I don't
want to end up spending too much resources in doing releases (I am
talking as a PSC not as GeoSolutions). Moreover this might also impact
development negatively, IMHO.

I still think I'm -1 on doing IRC meetings, especially if just once a
month.

The reasoning is as follows. The mail approach suggested in the GSIP
allows everybody to contribute their updates as they have 10 minutes
of spare time, and those are only used if they have anything
to provide updates for. It's really minimal effort.

The roadmap manager has just to send a summary mail a week and
gather the feedback in the wiki page. I would be surprised if that
took more than one hour a week. And if we do that on a rotation
basis, this "effort" happens only once every few months.
I don't think it's unreasonable to ask and allows everybody to
have a clear idea of where the project is going.

It has to be clear thought that we need to be easy going on this.
If we start being anal and complain about every little missed detail
with the release manager we're not going to go very far.
The process has to keep things up to date, but be lightweight as well
(thus only one round of mails a week and a wiki page update).
Even roadmap management is a community effort, a release manager
is there to ensure it happens to a certain extent, but everybody
is called to help out.

If we do proper rotation we'll
end up being one of the two figures once every 5-10 months
depending on the release frequency.
If a PSC member cannot bear to donate the project maintenance
2-4 days every 10 months he probably has no business
sitting in the PSC to start with. At least imho.

Cheers
Andrea

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

15

Ciao Andrea,
please, read below...

-------------------------------------------------------
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 Tue, Nov 24, 2009 at 12:09 PM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

Dear all,
providing some feedback.

I think that a 1 month release cycle may be too much of a burden,
especially since we have nightly builds that people can use, therefore
I would suggest to reconsider this timing.

...

The key for me is having PSC decide when the release should be done,
still, having a tentative timeline (once every month) in place, but
the process should not be automagical but rather based on minimal
consensus. I think that this would be a good balance between the
"release eraly release often" and the fact that developers tend to do
development instead of packaging :-).
If people talk and decide it is good a time to do a release, I bet
there will be no issue in finding volunteers to actually do it; on the
other end, I would be resilient to volunteer for a release that ust
contains a few bug fixes over a previous release thas was done just
one month ago. Moreover if we think about involving, code freeze,
anouncement on the devel list, test week, etc.. I think there would a
risk for us to end up devoting a little to much resource/attentions to
the release process.

I agree on the general reasoning. In the end it's almost obvious, if
there is no one interested and available to do a release, then no
release is done.

My perspective is different. To me saying that we should make a
release once every month is different than saying we should gather
feedback each month on whether to make or not a release.
If I were a user, if we went for approach a> I would expect a release
each month and I would draw a bad impression if not seeing it. On the
other, approach b) tend to put more responsibilities in the hands of
the developers/users who actually wants to see a release.
I am not a fan of the waterfall approach but rather of the organized
bazaar approach, hence I tend to prefer b) which should try to create
and share workload on a consensus bases.

Of course this approach might not prove to work if we don't manage to
keep communication efficient, that is why I suggested a 1h IRC chat
once every month (separate email on its way).

On a more philosophical level, I think that as a general goal we
should try to project a strong and professional image on our users but
giving us rules to manage important processes like releases, proposals
and so on.
Otherwise, sometimes I fear that we are moving a bit away from what OS
should be about (at leat IMHO) and we try to get to close to what
Commercial Software does (wrong). As an instance I am not convinced
that regular releases would project more professionalism and
robustness, probably they might if we are talking about completely
uneducated OS users, but still, I guess that there are more important
things that we (ok, that was an I) should spend time on, in order
achieve these goals like documentation. Ok ,end of rant.

Simone.

And if someone wants to push for a monthly release, well, he can,
he just has to make himself available to do the release tasks.

I've changed the GSIP to incorporate your feedback:
- removed hard references to monthly releases and worded it so that
actual dates take into consideration available resources
- asked the release announcement to include thanks to both roadmap
and release managers, and the companies backing them, to provide
both with the respect and gratitude they deserve for the work done.

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

16

Ciao Andrea,
please read below...
-------------------------------------------------------
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 Tue, Nov 24, 2009 at 12:19 PM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

I am +1 about doing an IRC meeting like once every month to perform
better communication between PSC/developers about the release, as well
as about the process itself and I would consider that meeting the time
to schedule new releases. I mean, saying that we should discuss about
releases once every month is ok with me, saying we should actually do
a release once a month is not ok with me. I'd like not to concentrate
too much on burocracy but rather on features and quality and I don't
want to end up spending too much resources in doing releases (I am
talking as a PSC not as GeoSolutions). Moreover this might also impact
development negatively, IMHO.

I still think I'm -1 on doing IRC meetings, especially if just once a
month.

The reasoning is as follows. The mail approach suggested in the GSIP
allows everybody to contribute their updates as they have 10 minutes
of spare time, and those are only used if they have anything
to provide updates for. It's really minimal effort.

The roadmap manager has just to send a summary mail a week and
gather the feedback in the wiki page. I would be surprised if that
took more than one hour a week. And if we do that on a rotation
basis, this "effort" happens only once every few months.
I don't think it's unreasonable to ask and allows everybody to
have a clear idea of where the project is going.

The suggestion of an IRC once a month comes from experience. I find
email a bit dispersive, generally speaking, therefore I tend to prefer
a short chat once in a while than many emails over a few days.
I mean, we can make it optional, the release manager (or anyine via
email) could suggest to hold the IRC chat and propose a time. People
can reject the idea or accept.
I understand this is similar to a
synchronized (attendees)
{
   attendees.attend_irc_chat();
}

but if we pay attention to:

1> reduce the number of times we actually do the IRC
2> reduce the time we use for the IRC

synchronization should not scare us :slight_smile:

It has to be clear thought that we need to be easy going on this.
If we start being anal and complain about every little missed detail
with the release manager we're not going to go very far.
The process has to keep things up to date, but be lightweight as well
(thus only one round of mails a week and a wiki page update).
Even roadmap management is a community effort, a release manager
is there to ensure it happens to a certain extent, but everybody
is called to help out.

Agreed.

If we do proper rotation we'll
end up being one of the two figures once every 5-10 months
depending on the release frequency.
If a PSC member cannot bear to donate the project maintenance
2-4 days every 10 months he probably has no business
sitting in the PSC to start with. At least imho.

Agreed, this is also a responsabily for all PSC members.

Ciao,
Simone.

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

17

Simone Giannecchini ha scritto:

My perspective is different. To me saying that we should make a
release once every month is different than saying we should gather
feedback each month on whether to make or not a release.
If I were a user, if we went for approach a> I would expect a release
each month and I would draw a bad impression if not seeing it. On the
other, approach b) tend to put more responsibilities in the hands of
the developers/users who actually wants to see a release.
I am not a fan of the waterfall approach but rather of the organized
bazaar approach, hence I tend to prefer b) which should try to create
and share workload on a consensus bases.

Given we're talking about a GSIP here, can you provide an alternate
wording on what the GSIP should contain then?

From what I gather above there is no way to tell when a release
will be done. It's moving from the "release early, release often"
to the "it's done when it's done" model, which gives neither users
nor developers any clue on when the release will be actually available.
The latter being bad since quite a few developers fix the critical
bugs only one week before the release (bad habit, but I can't force
people to behave otherwise).

Cheers
Andrea

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

18

Simone Giannecchini ha scritto:

The suggestion of an IRC once a month comes from experience. I find
email a bit dispersive, generally speaking, therefore I tend to prefer
a short chat once in a while than many emails over a few days.
I mean, we can make it optional, the release manager (or anyine via
email) could suggest to hold the IRC chat and propose a time. People
can reject the idea or accept.
I understand this is similar to a
synchronized (attendees)
{
   attendees.attend_irc_chat();
}

but if we pay attention to:

1> reduce the number of times we actually do the IRC
2> reduce the time we use for the IRC

synchronization should not scare us :slight_smile:

The problem I have with once a month is that a lot happens in
such a time.
For example, now I know Justin has the resource/publishing split
almost ready, and he should synchronize with you for the Hibernate
catalog as both hit a certain set of classes.

Shall we wait a month to talk about that? Of course not.
We can maybe reverse the situation: we use the mail for roadmap
updates when people need to discuss something, and IRC monthly
to force people to talk (since people tend to forget to talk
and just go code).

In any case, having a point person to keep the wiki page up to
date when any roadmap related discussion happens is important, as
it provides some guarantee the updates do happen.

Cheers
Andrea

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

19

On Tue, Nov 24, 2009 at 12:58 PM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

My perspective is different. To me saying that we should make a
release once every month is different than saying we should gather
feedback each month on whether to make or not a release.
If I were a user, if we went for approach a> I would expect a release
each month and I would draw a bad impression if not seeing it. On the
other, approach b) tend to put more responsibilities in the hands of
the developers/users who actually wants to see a release.
I am not a fan of the waterfall approach but rather of the organized
bazaar approach, hence I tend to prefer b) which should try to create
and share workload on a consensus bases.

Given we're talking about a GSIP here, can you provide an alternate
wording on what the GSIP should contain then?

From what I gather above there is no way to tell when a release
will be done. It's moving from the "release early, release often"
to the "it's done when it's done" model, which gives neither users
nor developers any clue on when the release will be actually available.
The latter being bad since quite a few developers fix the critical
bugs only one week before the release (bad habit, but I can't force
people to behave otherwise).

I am still try to convince myself that the "release early, release
often" is a good approach. My preference goes to "release when it's
worth, release something that is rock solid"
and to my knowledge other OS project follow the latter rather than the
former. As an instance I don't see a GDAL or MapServer every month.
This is probably due to the fact that for software like geoserver
there is not much of a difference between a substantial release like
2.0 or a bug fix release, the cost of making the release is similar or
comparable. "release early, release often" applies well to software
that comes in large package with an automatic update mechanism, it
does, e.g. OS like ubuntu, where the new release can be seen (at leat
IMHO) as the updates.
Comparing this to what we should do, I believe that:

1> nightly builds can do what automatic updates do for open source OS
("release early, release often")
2> monthly synch point is useful to let users and other developers
know where we are and decide if we have enough fixes/improvements to
make a release. "release when it's worth, release something that is
rock solid"

Notice that although we might decide to skip a monthly release, to
balance the fact that we may in principle end up never doing a
release, I would add the rule that after we can skip the release up to
twice in a row then we MUST make a release. If we fail, well, then we
should reset the PSC. This means that we know that we are going to
make a release at least every three months. This is my suggestion.

Simone.

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

20

On Tue, Nov 24, 2009 at 1:13 PM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

The suggestion of an IRC once a month comes from experience. I find
email a bit dispersive, generally speaking, therefore I tend to prefer
a short chat once in a while than many emails over a few days.
I mean, we can make it optional, the release manager (or anyine via
email) could suggest to hold the IRC chat and propose a time. People
can reject the idea or accept.
I understand this is similar to a
synchronized (attendees)
{
attendees.attend_irc_chat();
}

but if we pay attention to:

1> reduce the number of times we actually do the IRC
2> reduce the time we use for the IRC

synchronization should not scare us :slight_smile:

The problem I have with once a month is that a lot happens in
such a time.
For example, now I know Justin has the resource/publishing split
almost ready, and he should synchronize with you for the Hibernate
catalog as both hit a certain set of classes.

Shall we wait a month to talk about that? Of course not.
We can maybe reverse the situation: we use the mail for roadmap
updates when people need to discuss something, and IRC monthly
to force people to talk (since people tend to forget to talk
and just go code).

Ehm, that is exaclty what I meant :slight_smile:
I would mention IRC as a why to quickly round the discussion about the
release, in case there are points to address where emails would take
too much time.
IRC should not replace anything but come into play if/when needed.

In any case, having a point person to keep the wiki page up to
date when any roadmap related discussion happens is important, as
it provides some guarantee the updates do happen.

I did not see the IRC as a replacement for anything, just as an
(optional) addition.

Simone.

Cheers
Andrea

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