Thanks for the input guys. I can say that I can definitely vouch for that
the fact that OpenGeo is committed to pushing on geoserver 2.2 and moving
that toward stability, in the short term.
The security work is the last major destabilizing change coming down from
us. The focus over the next few months will definitely be to push on betas,
etc... moving torward 2.2 RC and an official 2.2 release.
So in that respect i think going with beta makes sense as we will
definitely be focused on fixing bugs, pushing out another beta soon (i
think one month makes sense) that will be much more stable and an
improvement on the beta that is soon to come.
On Tue, Apr 3, 2012 at 4:32 PM, Chris Holmes <[email protected]> wrote:
> Not that my answer should surprise anyone, as I'm most always the
> voice of pushing for living more on the edge (but appreciate it always
> balanced by more conservative voices, as the dialog and balance is
> what makes this community work so well).
>
> But my vote is to call it beta. Mostly from the perspective of
> attracting more beta testers, as Andrea points out. I think we'll get
> a lot more people checking it out if we call it 'beta'. It is a first
> beta, and in the blog post we can advertise it as such. But I like
> alphas for when we still may put more major things in to the release
> or when it's super experimental ideas (like first app-schema work) /
> we know it's going to be buggy. Betas imho just need to get better
> each time. And I think OpenGeo is interested in stability sooner
> rather than later, so can hopefully put time in to fixing the blocker
> and critical bugs and helping get releases out.
>
> So yeah, I'd agree if we can get commitment from someone to put out
> another beta in a month (or less if there's truly blocker bugs) then
> we should go for beta. I'm no longer driving OpenGeo product planning,
> but hopefully Justin could secure resources to commit to that.
>
> But yeah, I think the month time frame sounds reasonable, with the
> option to do more often if desired / there are blocker bugs.
>
> C
>
> On Tue, Apr 3, 2012 at 3:31 AM, Andrea Aime
> <[email protected]> wrote:
> > On Tue, Apr 3, 2012 at 8:15 AM, Justin Deoliveira <[email protected]>
> > wrote:
> >>
> >> Hi all,
> >>
> >> As far as I know the last major development change coming down the pipe
> >> that is planned for 2.2 is the security work. I am just working on a
> couple
> >> more tutorials to better the user documentation story, but the work is
> >> generally ready to be committed. I hope to have the work committed
> >> by tomorrow (Tuesday western time) unless there are any objections.
> >>
> >> After which I would like to propose the first alpha/beta release of the
> >> 2.2 series. Part of the motivation is having a release of 2.2 in place
> >> before the foss4gna conference next week. Andrea and myself will be
> >> delivering a talk titled "GeoServer, What's new in 2.2" in which we are
> >> going to survey all new features that will be coming with 2.2. IT would
> be
> >> awesome to have a release to supplement the talk with.
> >>
> >> Any objections? I wouldn't be getting to the release until later this
> >> week.
> >>
> >> Also, preferences to whether it be an alpha or a beta? I am thinking of
> >> staying on the safe side and calling it alpha just because it will be so
> >> close after the big security commit. But I could go either way. I know
> we
> >> have released pretty unstable betas in the past so it might not be too
> >> unreasonable. But no strong opinion.
> >>
> >> Thoughts?
> >
> >
> > Hmm.. if we call it an alpha we're on the safe side regards to the
> quality
> > of the product we're delivering,
> > which is rather unknown after the large set of GSIP landed in such a
> short
> > time.
> > But very few people will be interested in checking it out (too
> adventorous I
> > guess).
> >
> > If we call it a beta we'll get more people trying it out though.
> >
> > I guess it boils down to the intentions of developers (and companies
> backing
> > them): if we call it a beta
> > we should be ready to treat it as such, something that we intend to work
> on,
> > bug fixing wise, in
> > order to go to RC and then a release, in a relatively short amount of
> time
> > (two months maybe?).
> > Which really means, allocating time to fix whatever issues pop up in the
> > beta, and time to do other
> > beta releases with a... monthly basis or so (don't take me too seriously
> > here, I'm just proposing something
> > to foster discussion).
> > And of course reactivate and fix the CITE tests on trunk.
> >
> > Cheers
> > Andrea
> >
> > --
> > -------------------------------------------------------
> > Ing. Andrea Aime
> > GeoSolutions S.A.S.
> > Tech lead
> >
> > Via Poggio alle Viti 1187
> > 55054 Massarosa (LU)
> > Italy
> >
> > phone: +39 0584 962313
> > fax: +39 0584 962313
> > mob: +39 339 8844549
> >
> > http://www.geo-solutions.it
> > http://geo-solutions.blogspot.com/
> > http://www.youtube.com/user/GeoSolutionsIT
> > http://www.linkedin.com/in/andreaaime
> > http://twitter.com/geowolf
> >
> > -------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Better than sec? Nothing is better than sec when it comes to
> > monitoring Big Data applications. Try Boundary one-second
> > resolution app monitoring today. Free.
> > http://p.sf.net/sfu/Boundary-dev2dev
> > _______________________________________________
> > Geoserver-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
