[Geoserver-devel] virtual services, 2.0.x or trunk?

GeoServer GeoServer Developer
1

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

   http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

2

Hi Justin;

Been a bit mad busy to respond; I would prefer you did the virtual-services work on 2.0.x in order to reduce your overhead in running a separate tag. It is still early days of the 2.0.x stream...

Jody

On 19/01/2010, at 11:08 AM, Justin Deoliveira wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

  http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Justin Deoliveira ha scritto:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Already gave a +0.5, did not change my mind in the meantime, like, the code looks good, it's tested, yet the change is big so I'm being a little cautious.

If no one objects I guess between me and Jody you're good to go?

Cheers
Andrea

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

4

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Ciao Simone,

You are quite right, I did say this, and have always tried to advocate for less work on the stable branch. Which was my original motivation for sending this email.

I am odds with myself. With my "GeoServer developer" hat on I would vote against this on 2.0.x. However with my "delivering to customer" hat on it is definitely more convenient for me to have this rolled into 2.0.x.

Perhaps if I shed some light on my alternative strategy of maintaining a branch, since it would not be a conventional branch as we have seen in GeoServer before.

I have been using git locally to manage the different repos I work on. And have been using the svn support built right into git to make the interaction between git and svn seamless. I can explain how I have been working if people are interested or think it would help make the decision either. I also don't want to patronize those who already use git and probably know more about it than I do :), so just let me know.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

  http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

6

Ciao Justin,
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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Tue, Jan 19, 2010 at 9:13 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Ciao Simone,

You are quite right, I did say this, and have always tried to advocate
for less work on the stable branch. Which was my original motivation for
sending this email.

I am odds with myself. With my "GeoServer developer" hat on I would vote
against this on 2.0.x. However with my "delivering to customer" hat on
it is definitely more convenient for me to have this rolled into 2.0.x.

Believe me, I know what you are talking about...

Perhaps if I shed some light on my alternative strategy of maintaining a
branch, since it would not be a conventional branch as we have seen in
GeoServer before.

I have been using git locally to manage the different repos I work on.
And have been using the svn support built right into git to make the
interaction between git and svn seamless. I can explain how I have been
working if people are interested or think it would help make the
decision either. I also don't want to patronize those who already use
git and probably know more about it than I do :), so just let me know.

I would split topics:

1> it is certainly interesting to know how you are managin your branch
with GIT I tried with HG but I have never been 100% happy.
It might probably be a good idea to setup a sibling GIT repo for
GeoServer for this kind of work, so that we make merging back easier.
Notice that I am not proposing to
move away from SVN I am proposing to move away from doing experiment
on an SVN branch.

2> my questions before were more formal than technical.
We have a rule to not make changes on a stable branch and if we want
to allow exceptions we should probably delimit them clearly from the
beginning.
I mean, I am not sure that the fact that extensive changes are done
in GIT and maintained for a bit is enough but in the end I would
probably be ok with that approach, although I would say we need some
(few) clear rules that can give us some more room to breathe.
Right now the decision making process is more or less, trust+talking
between devs.

If I have overlooked some rule in the dev guide, I apologize.

Ciao,
Simone.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

Ciao Simone,

Simone Giannecchini wrote:

<snip>

I would split topics:

1> it is certainly interesting to know how you are managin your branch
with GIT I tried with HG but I have never been 100% happy.
It might probably be a good idea to setup a sibling GIT repo for
GeoServer for this kind of work, so that we make merging back easier.
Notice that I am not proposing to
move away from SVN I am proposing to move away from doing experiment
on an SVN branch.

Agreed, after using git branches svn branches just seem unusable and unmaintainable. I will write up my findings when i get a second and star t that separate conversation.

2> my questions before were more formal than technical.
We have a rule to not make changes on a stable branch and if we want
to allow exceptions we should probably delimit them clearly from the
beginning.
I mean, I am not sure that the fact that extensive changes are done
in GIT and maintained for a bit is enough but in the end I would
probably be ok with that approach, although I would say we need some
(few) clear rules that can give us some more room to breathe.
Right now the decision making process is more or less, trust+talking
between devs.

I completely agree, at this point the decision making process about what is allowed and not allowed on the stable branch is pretty arbitrary. Something for the PSC to think about I guess.

If I have overlooked some rule in the dev guide, I apologize.

Ciao,
Simone.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

  http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

8

On Wed, Jan 20, 2010 at 3:20 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Ciao Simone,

Simone Giannecchini wrote:

<snip>

I would split topics:

1> it is certainly interesting to know how you are managin your branch
with GIT I tried with HG but I have never been 100% happy.
It might probably be a good idea to setup a sibling GIT repo for
GeoServer for this kind of work, so that we make merging back easier.
Notice that I am not proposing to
move away from SVN I am proposing to move away from doing experiment
on an SVN branch.

Agreed, after using git branches svn branches just seem unusable and
unmaintainable. I will write up my findings when i get a second and star t
that separate conversation.

That would be great, we could make official use of GIT for this kind
of work and make it a recommended practice, or at least that would be
a good start.

2> my questions before were more formal than technical.
We have a rule to not make changes on a stable branch and if we want
to allow exceptions we should probably delimit them clearly from the
beginning.
I mean, I am not sure that the fact that extensive changes are done
in GIT and maintained for a bit is enough but in the end I would
probably be ok with that approach, although I would say we need some
(few) clear rules that can give us some more room to breathe.
Right now the decision making process is more or less, trust+talking
between devs.

I completely agree, at this point the decision making process about what is
allowed and not allowed on the stable branch is pretty arbitrary. Something
for the PSC to think about I guess.

I agree, but before pushing on this I would like to explore the GIT idea.
Payed work on stable branches is important for me, therefore I am keen
to explore ways to formalize how we can do it.

Simone.

If I have overlooked some rule in the dev guide, I apologize.

Ciao,
Simone.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how
i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts
the
world's best and brightest in the field, creating opportunities for
Conference
attendees to learn about information security's most important issues
through
interactions with peers, luminaries and emerging and established
companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for
Conference
attendees to learn about information security's most important issues
through
interactions with peers, luminaries and emerging and established
companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

9

2> my questions before were more formal than technical.
We have a rule to not make changes on a stable branch and if we want
to allow exceptions we should probably delimit them clearly from the
beginning.
I mean, I am not sure that the fact that extensive changes are done
in GIT and maintained for a bit is enough but in the end I would
probably be ok with that approach, although I would say we need some
(few) clear rules that can give us some more room to breathe.
Right now the decision making process is more or less, trust+talking
between devs.

Thanks for splitting topics Simone, it's definitely important to talk about this one on it's own.

I agree that some base guidelines are very important. Then whenever anyone gets paid work from a client they could look at the guidelines and figure out if the work would have to fall on trunk or could go on a stable branch. I think it's safe to say most every client would prefer their work done on a stable branch, even though many accept it's not possible.

The PSC of course could still decide to break the rules at its discretion. But I think it'd be better for the default to be more conservative, instead of the vague 'ask' process it is now. Then we'd all be able to set client expectations. And for clients that really need it we'd all know when we have to ask ahead of time. And can come up with alternate strategies to deliver what's needed against a stable branch, like using GIT.

What are people's thoughts on what those rules should be? How can we define them clearly?

Once we get some responses I'd be happy to at least help create a GSIP to formalize the rules and get them in to the developers guide. But I'm far from the code now so need help on how to define. I guess a decent place to start is why the changes for virtual services are 'major', and why the hibernate changes are 'major'. What it is about them that gives us pause.

Chris

If I have overlooked some rule in the dev guide, I apologize.

Ciao,
Simone.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

  http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

10

We've lived with not being able to put things onto the stable branch,
its only taken 7 years of dogged effort before we've found a customer
willing and able to fund getting things into the trunk :wink:

I think the pragmatic approach you suggest is good - default is
conservative but the PSC can overrule. Getting the trunk cut to a new
stable branch may be better in many cases that retrofitting
significant change to a (un)stable branch. When significant
architectural revamp is underway on trunk, its going to be costly to
port to a stable branch and trunk anyway - so we're just going to have
to look at each case on its merits,

Rob

On Thu, Jan 21, 2010 at 5:15 AM, Chris Holmes <cholmes@anonymised.com> wrote:

2> my questions before were more formal than technical.
We have a rule to not make changes on a stable branch and if we want
to allow exceptions we should probably delimit them clearly from the
beginning.
I mean, I am not sure that the fact that extensive changes are done
in GIT and maintained for a bit is enough but in the end I would
probably be ok with that approach, although I would say we need some
(few) clear rules that can give us some more room to breathe.
Right now the decision making process is more or less, trust+talking
between devs.

Thanks for splitting topics Simone, it's definitely important to talk
about this one on it's own.

I agree that some base guidelines are very important. Then whenever
anyone gets paid work from a client they could look at the guidelines
and figure out if the work would have to fall on trunk or could go on a
stable branch. I think it's safe to say most every client would prefer
their work done on a stable branch, even though many accept it's not
possible.

The PSC of course could still decide to break the rules at its
discretion. But I think it'd be better for the default to be more
conservative, instead of the vague 'ask' process it is now. Then we'd
all be able to set client expectations. And for clients that really
need it we'd all know when we have to ask ahead of time. And can come
up with alternate strategies to deliver what's needed against a stable
branch, like using GIT.

What are people's thoughts on what those rules should be? How can we
define them clearly?

Once we get some responses I'd be happy to at least help create a GSIP
to formalize the rules and get them in to the developers guide. But I'm
far from the code now so need help on how to define. I guess a decent
place to start is why the changes for virtual services are 'major', and
why the hibernate changes are 'major'. What it is about them that gives
us pause.

Chris

If I have overlooked some rule in the dev guide, I apologize.

Ciao,
Simone.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com.> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

11

In this case I was willing to give it a go because:
a) we have just released 2.0.1 (so we have some time for testing this functionality in 2.0.1)
b) the 2.0.x branch is very young and I kind of felt this capability was cut in order get 2.0.x out in time - indeed this limitation, the handling of the url paths, was a source of much discussion and confusion

As for the guideline of what makes it into stable and what does not - my comfort level is dictated by how much of the functionality can be done as a separate module. The greater the changes to "core" the less comfortable I am doing the work in the stable branch.

Note there is another option - do this change and release 2.1 (ie be totally honest and version control trunk based on the extent of changes to core). That is a little bit of trouble with respect to the GeoServer "product" story; but it would match what is happening to the codebase.

Personally I would be in favour of chewing through the point releases at a faster pace - if you look at Justin's commit and number of features graph we have really increased our output and we could reflect that activity in our version numbers. It would be an honest reflection of what is happening. Justin's work and SImone's work is significant and could be the centre piece of new point release.

Jody

On 21/01/2010, at 9:10 AM, Rob Atkinson wrote:

We've lived with not being able to put things onto the stable branch,
its only taken 7 years of dogged effort before we've found a customer
willing and able to fund getting things into the trunk :wink:

I think the pragmatic approach you suggest is good - default is
conservative but the PSC can overrule. Getting the trunk cut to a new
stable branch may be better in many cases that retrofitting
significant change to a (un)stable branch. When significant
architectural revamp is underway on trunk, its going to be costly to
port to a stable branch and trunk anyway - so we're just going to have
to look at each case on its merits,

Rob

On Thu, Jan 21, 2010 at 5:15 AM, Chris Holmes <cholmes@anonymised.com> wrote:

2> my questions before were more formal than technical.
We have a rule to not make changes on a stable branch and if we want
to allow exceptions we should probably delimit them clearly from the
beginning.
I mean, I am not sure that the fact that extensive changes are done
in GIT and maintained for a bit is enough but in the end I would
probably be ok with that approach, although I would say we need some
(few) clear rules that can give us some more room to breathe.
Right now the decision making process is more or less, trust+talking
between devs.

Thanks for splitting topics Simone, it's definitely important to talk
about this one on it's own.

I agree that some base guidelines are very important. Then whenever
anyone gets paid work from a client they could look at the guidelines
and figure out if the work would have to fall on trunk or could go on a
stable branch. I think it's safe to say most every client would prefer
their work done on a stable branch, even though many accept it's not
possible.

The PSC of course could still decide to break the rules at its
discretion. But I think it'd be better for the default to be more
conservative, instead of the vague 'ask' process it is now. Then we'd
all be able to set client expectations. And for clients that really
need it we'd all know when we have to ask ahead of time. And can come
up with alternate strategies to deliver what's needed against a stable
branch, like using GIT.

What are people's thoughts on what those rules should be? How can we
define them clearly?

Once we get some responses I'd be happy to at least help create a GSIP
to formalize the rules and get them in to the developers guide. But I'm
far from the code now so need help on how to define. I guess a decent
place to start is why the changes for virtual services are 'major', and
why the hibernate changes are 'major'. What it is about them that gives
us pause.

Chris

If I have overlooked some rule in the dev guide, I apologize.

Ciao,
Simone.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com..> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

  http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

12

I tend to have concerns about 'looking at each case on its merits' without some pretty solid guidelines as to what merits we need to consider. This in part comes from my lack of familiarity with the code; I won't necessarily know how much is being touched or how hard it will be to port from stable to trunk.

In general I prefer the approach of no user-facing or expected behaviour changing updates to stable. In this case, as an example, it seems more like an addition than a change, so I have little trouble letting it in provided sufficient tests come along with it.

In principle, I think the best bet for big changes (those not fitting the above criteria) is cutting trunk to a new stable branch, but that's dependent on what's happening on trunk at any given time; it simply may not be ready for the cut. This then becomes another case of not knowing until you ask.

--
Mark

Rob Atkinson wrote:

We've lived with not being able to put things onto the stable branch,
its only taken 7 years of dogged effort before we've found a customer
willing and able to fund getting things into the trunk :wink:

I think the pragmatic approach you suggest is good - default is
conservative but the PSC can overrule. Getting the trunk cut to a new
stable branch may be better in many cases that retrofitting
significant change to a (un)stable branch. When significant
architectural revamp is underway on trunk, its going to be costly to
port to a stable branch and trunk anyway - so we're just going to have
to look at each case on its merits,

Rob

On Thu, Jan 21, 2010 at 5:15 AM, Chris Holmes <cholmes@anonymised.com> wrote:

2> my questions before were more formal than technical.
We have a rule to not make changes on a stable branch and if we want
to allow exceptions we should probably delimit them clearly from the
beginning.
I mean, I am not sure that the fact that extensive changes are done
in GIT and maintained for a bit is enough but in the end I would
probably be ok with that approach, although I would say we need some
(few) clear rules that can give us some more room to breathe.
Right now the decision making process is more or less, trust+talking
between devs.

Thanks for splitting topics Simone, it's definitely important to talk
about this one on it's own.

I agree that some base guidelines are very important. Then whenever
anyone gets paid work from a client they could look at the guidelines
and figure out if the work would have to fall on trunk or could go on a
stable branch. I think it's safe to say most every client would prefer
their work done on a stable branch, even though many accept it's not
possible.

The PSC of course could still decide to break the rules at its
discretion. But I think it'd be better for the default to be more
conservative, instead of the vague 'ask' process it is now. Then we'd
all be able to set client expectations. And for clients that really
need it we'd all know when we have to ask ahead of time. And can come
up with alternate strategies to deliver what's needed against a stable
branch, like using GIT.

What are people's thoughts on what those rules should be? How can we
define them clearly?

Once we get some responses I'd be happy to at least help create a GSIP
to formalize the rules and get them in to the developers guide. But I'm
far from the code now so need help on how to define. I guess a decent
place to start is why the changes for virtual services are 'major', and
why the hibernate changes are 'major'. What it is about them that gives
us pause.

Chris

If I have overlooked some rule in the dev guide, I apologize.

Ciao,
Simone.

-Justin

Simone Giannecchini wrote:

Ciao Justin,
I checked the patch a little bit as well as the proposal page and they
both look good to me, I think it is something we need, therefore I am
inclined to say go ahead and commit.

At the same time, I have a doubt/concern. When we discussed the
changes to make the hibernate catalog happy, you told me that you were
not happy to make relevant changes on the 2.0.x branch. I agreed with
your judgement and therefore we tried to find a workaround and
postponed part of the associated work. With the patch you propose I
believe we are in the same situation, actually, probably worse since
the changes are substantial and extensive. Therefore my doubt/concern,
is as follows, assuming that the work that each one of us do has a
stakeholder, internal or external, why this time we should allow this
change to be included? What is the reference UoM for "relevant
changes" on a stable branch?

As I said I am willing to give at least a +0 to your work but I think
that the questions I asked above are important to me, especially as a
Company, since as you pointed out, mantaining branches and local
version has a cost and I would like to clarify a bit the key factor
for deciding what can be included in a stable branch and what cannot
be included.

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://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Mon, Jan 18, 2010 at 5:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

In a recent through I brought up the question about the virtual service
work being done on the stable branch:

http://old.nabble.com/virtual-services,-suitable-for-2.0.x--td27163335.html

However did not get much in terms of resolution from the PSC. So I want
to ask if there is anything more I can do to make the issue clearer or
there are any more outstanding questions.

Here is the issue with an updated patch:

  http://jira.codehaus.org/browse/GEOS-3768

Apologies for being pushy, i know everyone is extremely busy but this
work needs to be delivered to the customer soon and I need to know how i
am going to maintain it.

Thanks.

-Justin

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
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.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

13

Chris Holmes ha scritto:

I agree that some base guidelines are very important. Then whenever anyone gets paid work from a client they could look at the guidelines and figure out if the work would have to fall on trunk or could go on a stable branch. I think it's safe to say most every client would prefer their work done on a stable branch, even though many accept it's not possible.

The PSC of course could still decide to break the rules at its discretion. But I think it'd be better for the default to be more conservative, instead of the vague 'ask' process it is now. Then we'd all be able to set client expectations. And for clients that really need it we'd all know when we have to ask ahead of time. And can come up with alternate strategies to deliver what's needed against a stable branch, like using GIT.

What are people's thoughts on what those rules should be? How can we define them clearly?

Providing a set of rules is kind of hard. Let me try with a list of
elements to consider when assessing the risk for a patch instead:
- Dimension. Is the patch affecting just one module or
   spreads out through all the code base?
- Core-ness. Is the patch affecting just an extension, a popular
   module such as wms/wfs, or a core module like ows/main?
- Attention to detail. Is the patch containing accurate javadoc and
   comments, is it easy to review?
- Testing. Are all the changed area covered by tests, is the new code
   covered by tests?
- Experience. Ok, this might be disputable, but anyways, what is the
   expertise of the person in the specific area being modified?
- Reviews. Has the patch been reviewed, is everybody comfortable with
   it?
- Production testing. This is not something we've seen a lot, but
   is the patch being used in some live site? Did it receive some
   actual usage? I think in general people would feel more comfortable
   about battlefield tested changes (by not means a requirement, but
   certainly a plus)

Cheers
Andrea

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