[Geoserver-devel] timing for RC1

Hi all,

As was discussed last week the plan is to start the RC1 release tomorrow. After thinking about the timing I have some reservations about calling tomorrows release an RC with regard to some fo the major changes that have taken place over the last few days and will happen tomorrow. Most notably the gwc/wms and the coming security changes. I am a little hesitant about starting a release directly after these changes land, and calling that release an RC.

Anyways perhaps I am putting too much though into what “RC” means but I just though I would voice the concern in case others feel the same, and present some possible alternatives that have crossed my mind.

  1. Call tomorrows release another beta, and actually give a bit of a cool down period before the official RC1 comes out that is restricted to bug fixes and more modest features and improvements.

  2. Wait a week before releasing RC1 to at least give some time for more testing from devs.

  3. Tell me to shut up for being a wimp and just release RC1 tomorrow. And if problems to pop up we just fix them and put out another RC quickly. Since hey it is not like we are going to run out of numbers.

  4. Other thoughts and alternatives welcome.

This does however beg the larger question about how we want to approach 2.1.0. Do we just continue full steam ahead and eventually choose a time to release 2.1.0? Or do we want some sort of ramp down period where we stick to more conservative development as we get closer to 2.1.0?

-Justin


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

+1 for option 1

I think your concerns are well justified, and only if someone had some
major funding milestone needing a RC today should we consider it.

Rob

On Fri, Jan 7, 2011 at 11:51 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
As was discussed last week the plan is to start the RC1 release tomorrow.
After thinking about the timing I have some reservations about
calling tomorrows release an RC with regard to some fo the major changes
that have taken place over the last few days and will happen tomorrow.
Most notably the gwc/wms and the coming security changes. I am a little
hesitant about starting a release directly after these changes land, and
calling that release an RC.
Anyways perhaps I am putting too much though into what "RC" means but I just
though I would voice the concern in case others feel the same, and present
some possible alternatives that have crossed my mind.
1. Call tomorrows release another beta, and actually give a bit of a cool
down period before the official RC1 comes out that is restricted to bug
fixes and more modest features and improvements.
2. Wait a week before releasing RC1 to at least give some time for more
testing from devs.
3. Tell me to shut up for being a wimp and just release RC1 tomorrow. And if
problems to pop up we just fix them and put out another RC quickly. Since
hey it is not like we are going to run out of numbers.
4. Other thoughts and alternatives welcome.
This does however beg the larger question about how we want to approach
2.1.0. Do we just continue full steam ahead and eventually choose a time to
release 2.1.0? Or do we want some sort of ramp down period where we stick to
more conservative development as we get closer to 2.1.0?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment,
and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

If we go with #1 I say that it should be restricted to bug fixes only, no modest features. Make a psuedo-RC and really freeze things, make people aware it’s the final beta, etc.

I’m not a fan of #2, I think either way we should put out a release that gets more user testing on the 2 new features.

As for 2.1.0, my vote is we should make RC’s real candidates for release, no feature development, and once we go a week (or some other time we feel comfortable with) without a show stopper bug we just call the last RC the .0

On Thu, Jan 6, 2011 at 7:51 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

As was discussed last week the plan is to start the RC1 release tomorrow. After thinking about the timing I have some reservations about calling tomorrows release an RC with regard to some fo the major changes that have taken place over the last few days and will happen tomorrow. Most notably the gwc/wms and the coming security changes. I am a little hesitant about starting a release directly after these changes land, and calling that release an RC.

Anyways perhaps I am putting too much though into what “RC” means but I just though I would voice the concern in case others feel the same, and present some possible alternatives that have crossed my mind.

  1. Call tomorrows release another beta, and actually give a bit of a cool down period before the official RC1 comes out that is restricted to bug fixes and more modest features and improvements.

  2. Wait a week before releasing RC1 to at least give some time for more testing from devs.

  3. Tell me to shut up for being a wimp and just release RC1 tomorrow. And if problems to pop up we just fix them and put out another RC quickly. Since hey it is not like we are going to run out of numbers.

  4. Other thoughts and alternatives welcome.

This does however beg the larger question about how we want to approach 2.1.0. Do we just continue full steam ahead and eventually choose a time to release 2.1.0? Or do we want some sort of ramp down period where we stick to more conservative development as we get closer to 2.1.0?

-Justin


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


Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl


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

On Fri, Jan 7, 2011 at 1:51 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
As was discussed last week the plan is to start the RC1 release tomorrow.
After thinking about the timing I have some reservations about
calling tomorrows release an RC with regard to some fo the major changes
that have taken place over the last few days and will happen tomorrow.
Most notably the gwc/wms and the coming security changes. I am a little
hesitant about starting a release directly after these changes land, and
calling that release an RC.

I had the same concern that's why I asked for a one week delay of the
RC release.
I guess that was lost in the discussion?
However Chris said it was ok to delay a few days.

Anyways perhaps I am putting too much though into what "RC" means but I just
though I would voice the concern in case others feel the same, and present
some possible alternatives that have crossed my mind.
1. Call tomorrows release another beta, and actually give a bit of a cool
down period before the official RC1 comes out that is restricted to bug
fixes and more modest features and improvements.
2. Wait a week before releasing RC1 to at least give some time for more
testing from devs.

+1 on this one, it's what me and Simone already proposed

3. Tell me to shut up for being a wimp and just release RC1 tomorrow. And if
problems to pop up we just fix them and put out another RC quickly. Since
hey it is not like we are going to run out of numbers.
4. Other thoughts and alternatives welcome.
This does however beg the larger question about how we want to approach
2.1.0. Do we just continue full steam ahead and eventually choose a time to
release 2.1.0? Or do we want some sort of ramp down period where we stick to
more conservative development as we get closer to 2.1.0?

I guess once RC1 is out only bug fixes are in.
I'd suggest to branch off 2.1.x as we cut the RC and let trunk go full steam, we
can backport whatever changes after 2.1.0 is out with review and whatnot.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

On Fri, Jan 7, 2011 at 8:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

1. Call tomorrows release another beta, and actually give a bit of a cool
down period before the official RC1 comes out that is restricted to bug
fixes and more modest features and improvements.

Btw, did not read the other responses. This one works for me as well, I'm just
surprised by the change of mind after discussing the delay just a few days ago.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

On Fri, 2011-01-07 at 08:35 +0100, Andrea Aime wrote:

On Fri, Jan 7, 2011 at 8:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
>> 1. Call tomorrows release another beta, and actually give a bit of a cool
>> down period before the official RC1 comes out that is restricted to bug
>> fixes and more modest features and improvements.

Btw, did not read the other responses. This one works for me as well, I'm just
surprised by the change of mind after discussing the delay just a few days ago.

Looks like I missed that discussion, as I usually do when overwhelmed,
sorry.

Any case, I've my own selfish reasons not to call tomorrow's release an
RC. Actually I'm more towards option #2, waiting a week to release, as I
want to include the following new feature (which complements gwc/wms
integration, and for which I'm obviously working overtime, given the
time I'm writing this at) and wouldn't feel comfortable doing so for an
RC. See attached screenshot.

With this and Justin's concerns in mind, which I share, I think if
there's a release tomorrow it should be another beta. And it bothers me
cause though I didn't sleep today at all, I won't make it for tomorrow
cause I have 500km ride in less than two hours...

If we waited till next week, we wouldn't be doubling efforts in release
processes and I could get diskquota in. At the same time I don't want to
stop others if tomorrow's release is needed, so I'll abstain from a vote
with a preference to wait, or a plea to let me get this functionality
after the fact and before we call 2.1.x for a feature freeze.

Cheers,
Gabriel

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

(attachments)

diskquota_integration.png

Ah, sorry, reading back over the other responses I realize I got confused. Since Simone and I were talking about it more than a week ahead of time I parsed ‘one week delay’ as something like one week from when you got back, and that friday was the day. My ‘a couple days extra’ meant in to next week, not the following week. Reading back it looks like my error. Next time though let’s say explicit dates that we’re talking about, since it can be hard to unpack when things are relative.

… And Gabriel’s proposed patch is pretty damn sweet. So I guess I’ll even back down from my desire to make a beta that’s a feature freeze. People doing cool stuff every single week makes it hard to do releases :stuck_out_tongue:

Ok, sorry for all the noise, let’s just go with the plan I didn’t realize I agreed to of RC1 next week, by the 14th at the absolute latest. I will try to read email more closely in the future and not cause so much confusion. As for beta4, I guess there’s no real compelling reason to do it, especially since it looks like GSIP-57 isn’t in yet. I guess the one reason to do a beta is if we want more testing for gsip 57 and gwc/wms integration, but it seems like if we get things in now then the nightlies should get some testing.

And +1 on branching for RC1 and continuing work on trunk, freezing all features at rc1.

C

On Fri, Jan 7, 2011 at 2:35 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jan 7, 2011 at 8:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

  1. Call tomorrows release another beta, and actually give a bit of a cool
    down period before the official RC1 comes out that is restricted to bug
    fixes and more modest features and improvements.

Btw, did not read the other responses. This one works for me as well, I’m just
surprised by the change of mind after discussing the delay just a few days ago.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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



Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers’ information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl


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

On Fri, Jan 7, 2011 at 2:59 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Ah, sorry, reading back over the other responses I realize I got confused.
Since Simone and I were talking about it more than a week ahead of time I
parsed 'one week delay' as something like one week from when you got back,
and that friday was the day. My 'a couple days extra' meant in to next
week, not the following week. Reading back it looks like my error. Next
time though let's say explicit dates that we're talking about, since it can
be hard to unpack when things are relative.

... And Gabriel's proposed patch is pretty damn sweet. So I guess I'll
even back down from my desire to make a beta that's a feature freeze.
People doing cool stuff every single week makes it hard to do releases :stuck_out_tongue:

Ok, sorry for all the noise, let's just go with the plan I didn't realize I
agreed to of RC1 next week, by the 14th at the absolute latest. I will try
to read email more closely in the future and not cause so much confusion.
As for beta4, I guess there's no real compelling reason to do it, especially
since it looks like GSIP-57 isn't in yet. I guess the one reason to do a
beta is if we want more testing for gsip 57 and gwc/wms integration, but it
seems like if we get things in now then the nightlies should get some
testing.

GSIP57 has been committed a few hours ago, so it's in.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

Ah ok, sorry I did not catch it. I had a lot of email to catch up on after 2 weeks of holidays and this one must have slipped through the cracks.

On Fri, Jan 7, 2011 at 12:33 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jan 7, 2011 at 1:51 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
As was discussed last week the plan is to start the RC1 release tomorrow.
After thinking about the timing I have some reservations about
calling tomorrows release an RC with regard to some fo the major changes
that have taken place over the last few days and will happen tomorrow.
Most notably the gwc/wms and the coming security changes. I am a little
hesitant about starting a release directly after these changes land, and
calling that release an RC.

I had the same concern that’s why I asked for a one week delay of the
RC release.
I guess that was lost in the discussion?
However Chris said it was ok to delay a few days.

Anyways perhaps I am putting too much though into what “RC” means but I just
though I would voice the concern in case others feel the same, and present
some possible alternatives that have crossed my mind.

  1. Call tomorrows release another beta, and actually give a bit of a cool
    down period before the official RC1 comes out that is restricted to bug
    fixes and more modest features and improvements.
  2. Wait a week before releasing RC1 to at least give some time for more
    testing from devs.

+1 on this one, it’s what me and Simone already proposed

  1. Tell me to shut up for being a wimp and just release RC1 tomorrow. And if
    problems to pop up we just fix them and put out another RC quickly. Since
    hey it is not like we are going to run out of numbers.
  2. Other thoughts and alternatives welcome.
    This does however beg the larger question about how we want to approach
    2.1.0. Do we just continue full steam ahead and eventually choose a time to
    release 2.1.0? Or do we want some sort of ramp down period where we stick to
    more conservative development as we get closer to 2.1.0?

I guess once RC1 is out only bug fixes are in.
I’d suggest to branch off 2.1.x as we cut the RC and let trunk go full steam, we
can backport whatever changes after 2.1.0 is out with review and whatnot.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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



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

Great, so RC1 next week it is with no release this week. This actually works a little nicer as it gives us a week to organize the corresponding geotools release as well.

On Fri, Jan 7, 2011 at 1:26 AM, Gabriel Roldán <groldan@anonymised.com> wrote:

On Fri, 2011-01-07 at 08:35 +0100, Andrea Aime wrote:

On Fri, Jan 7, 2011 at 8:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

  1. Call tomorrows release another beta, and actually give a bit of a cool
    down period before the official RC1 comes out that is restricted to bug
    fixes and more modest features and improvements.

Btw, did not read the other responses. This one works for me as well, I’m just
surprised by the change of mind after discussing the delay just a few days ago.

Looks like I missed that discussion, as I usually do when overwhelmed,
sorry.

Any case, I’ve my own selfish reasons not to call tomorrow’s release an
RC. Actually I’m more towards option #2, waiting a week to release, as I
want to include the following new feature (which complements gwc/wms
integration, and for which I’m obviously working overtime, given the
time I’m writing this at) and wouldn’t feel comfortable doing so for an
RC. See attached screenshot.

With this and Justin’s concerns in mind, which I share, I think if
there’s a release tomorrow it should be another beta. And it bothers me
cause though I didn’t sleep today at all, I won’t make it for tomorrow
cause I have 500km ride in less than two hours…

If we waited till next week, we wouldn’t be doubling efforts in release
processes and I could get diskquota in. At the same time I don’t want to
stop others if tomorrow’s release is needed, so I’ll abstain from a vote
with a preference to wait, or a plea to let me get this functionality
after the fact and before we call 2.1.x for a feature freeze.

Cheers,
Gabriel

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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



Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers’ information secure
and instills the confidence they need to proceed with transactions.

http://p.sf.net/sfu/oracle-sfdevnl


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


Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers


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