On Wed, May 2, 2012 at 9:27 AM, Andrea Aime <[email protected]>wrote:
> On Tue, May 1, 2012 at 5:54 PM, Justin Deoliveira <[email protected]>wrote:
>
>> In general I think it looks great, a few things though. I think given the
>> current effort to put out releases 1 month is probably asking a bit much
>> given the resources we have on the project. So I think to do one month
>> cycles we really do need to better automate our release process with a
>> hudson job that does most of the work.
>>
>> It would also be good to have some better defined (and perhaps stricter)
>> guidelines about what is acceptable to commit given the current phase of an
>> iteration. For instance obviously once we move to a stable or hardening
>> phase GSIP's that drastically alter the core are out of the question. It
>> would be good if we had a more concrete definition of "drastically alter
>> the core". Like should we be strict and say stable/hardening
>> means strictly only bug fixes? With a faster release cycle it could make
>> more sense to have stricter guidelines since if you don't get something
>> into this release there is one not too far off. This is exactly why we ran
>> into the fluerry of gsip issue... with another release 1.5 years away it
>> certainly puts the pressure on to cram stuff in.
>>
>> Anyways, great stuff. I like where this is going, big things from my
>> standpoint.
>>
>> 1. better automation of release, which i am happy to help with
>> 2. better guidelines for what type of development is acceptable during
>> what phases
>>
>
> Fully agree on the higher automation (tried to discuss some ideas about it
> in my
> original mail).
>
> About what is acceptable and not, what about the following:
> - stable series: only bug fixes and new features that do not require API
> changes
> or large patches to existing systems (that is, if you are contributing a
> new module
> the patch can be as large as you want, but a "bug fix" that rewrites
> half of WFS
> is not welcomed unless the PSC really really wants such change badly in)
> - trunk: free reign, but large changes still need a GSIP and reviews
> - hardening: no new features, only bug fixing to make sure people
> concentrate on
> that, if you have something new it has to go on trunk for the time being
>
These sounds reasonable to me. Obviously nothing is going to be black and
white but they are a good start and we can refine as need be. As part of
this proposal we should ensure they are described in the developer guide.
Having this rules written down somewhere we can point to easily will be
more effective than just coming up with a common unoffocial understanding
among PSC and core developers.
>
> The above should be, imho, taken more or less as strict rules that the PSC
> should
> try to enforce (the above, or whatever we come up with).
> That said, the PSC should be allowed to decide outside of the above rules
> in case of dire necessity (e.g., something that could threaten or damage
> the
> project severely if not done outside of the rules).
>
Certainly, the PSC should be able to make exceptions on a case by case
basis. Again it might be nice to enumerate what those are. In the past as
far as I know the biggest one has been that a client needs a significant
new feature, but needs it on a stable branch.
>
> 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
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users