On Tue, Nov 24, 2009 at 12:58 PM, Andrea Aime <aa...@opengeo.org> wrote:
> Simone Giannecchini ha scritto:
>> My perspective is different. To me saying that we should make a
>> release once every month is different than saying we should gather
>> feedback each month on whether to make or not a release.
>> If I were a user, if we went for approach a> I would expect a release
>> each month and I would draw a bad impression if not seeing it. On the
>> other, approach b) tend to put more responsibilities in the hands of
>> the developers/users who actually wants to see a release.
>> I am not a fan of the waterfall approach but rather of the organized
>> bazaar approach, hence I tend to prefer b) which should try to create
>> and share workload on a consensus bases.
>
> Given we're talking about a GSIP here, can you provide an alternate
> wording on what the GSIP should contain then?
>
> From what I gather above there is no way to tell when a release
> will be done. It's moving from the "release early, release often"
> to the "it's done when it's done" model, which gives neither users
> nor developers any clue on when the release will be actually available.
> The latter being bad since quite a few developers fix the critical
> bugs only one week before the release (bad habit, but I can't force
> people to behave otherwise).
I am still try to convince myself that the "release early, release
often" is a good approach. My preference goes to "release when it's
worth, release something that is rock solid"
and to my knowledge other OS project follow the latter rather than the
former. As an instance I don't see a GDAL or MapServer every month.
This is probably due to the fact that for software like geoserver
there is not much of a difference between a substantial release like
2.0 or a bug fix release, the cost of making the release is similar or
comparable. "release early, release often" applies well to software
that comes in large package with an automatic update mechanism, it
does, e.g. OS like ubuntu, where the new release can be seen (at leat
IMHO) as the updates.
Comparing this to what we should do, I believe that:
1> nightly builds can do what automatic updates do for open source OS
("release early, release often")
2> monthly synch point is useful to let users and other developers
know where we are and decide if we have enough fixes/improvements to
make a release. "release when it's worth, release something that is
rock solid"
Notice that although we might decide to skip a monthly release, to
balance the fact that we may in principle end up never doing a
release, I would add the rule that after we can skip the release up to
twice in a row then we MUST make a release. If we fail, well, then we
should reset the PSC. This means that we know that we are going to
make a release at least every three months. This is my suggestion.
Simone.
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
