See below...
On Wed, Nov 25, 2009 at 11:26 AM, Andrea Aime <[email protected]> wrote:
> Ben Caradoc-Davies ha scritto:
>
> On 24/11/09 19:19, Andrea Aime wrote:
>>
>>> If we do proper rotation we'll
>>> end up being one of the two figures once every 5-10 months
>>> depending on the release frequency.
>>> If a PSC member cannot bear to donate the project maintenance
>>> 2-4 days every 10 months he probably has no business
>>> sitting in the PSC to start with. At least imho.
>>>
>>
>> I am concerned that requiring PSC members to perform releases excludes
>> non-developers and intermittent developers from PSC membership, even though
>> they might have a major contribution to make to in the standards, usability,
>> or documentation spaces. I am sure there are those whose contribution to the
>> PSC I would value, but whom I would not like making a release. I think GSIP
>> 43 as it stands does not require PSC members to volunteer, and I support
>> this position. The PSC is about governance, not engineering work.
>>
>> Furthermore, there are competent (or at least willing) release engineers
>> who might not be on the PSC who should not be excluded.
>>
>
> Absolutely, I agree with you that anyone willing should be involved in
> the release process. What I meant was that the PSC has to be there if
> no one else is available. Governance is little good if things do not
> get done.
>
>
+10 for me on this point.
>
> Should we instead have a release roster, so the position rotates? This
>> need not be formed from PSC members. A written roster would give advance
>> warning to those expected to make a release, and give confidence to those
>> that usually end up doing the donkey work that they will not have to do it
>> *every* time. Such a roster would also expand the base of those with
>> experience making a release. We could also have a testing roster. I am not
>> sure about the roadmap.
>>
>> If there is a release roster, I volunteer to be on it, as long as it is
>> not just me. :-)
>>
>
> That would be very much appreciated. If my reading Simone's position
> is correct we're going to make releases as resources as available.
> I still like the idea of timed releases, as I know we can accumulate
> a significant amount of work in one month, let alone two
> (just look at the current 2.0.x situation, 47 tickets have been closed
> since 2.0.0:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+fixVersion+%3D+%222.0.1%22+AND+status+in+%28Resolved%2C+Closed%29+ORDER+BY+updated+DESC%2C+priority+DESC%2C+created+ASC
> )
>
>
I also agree with you on this point ... but if I'm interpreting well the
Simone's position, we should be careful creating too much aspectatives to
the users, who might be disappointed if for some reasons we miss or delay
too much a release ... we could just remark that in any case a release is
subject to voting or discussion or something like that?
> Not sure I'd want to plan release positions for the next 6 months, but
> I think it would be good incentive to have a page, linked from the
> releases announcement, that shows who did the last releases.
> Should be enough incentive to make a rotation happen without making
> it a rule?
>
> But yeah, having a known group of people that are able and ready to
> make releases is certainly a good idea. I'm just worried about
> adding to much rules/bureocracy on top of it.
>
>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
