[OPEN-ILS-DEV] Should GSOC schedule affect 2.3 (etc) release schedule?

[Lazar, Alexey Vladimirovich]

Generally, I think all contributed code should go through the equal review procedures and not specially prioritized, unless we are talking about critical fixes, but can be decided on a case-by-case basis or whatever the current process. I think keeping with release schedule is most important. I would rather see GSCO or any other code or feature come in a later release, but properly reviewed, tested and documented. 

> 1. Don't let it affect the schedule.  Any GSOC code that is completed early enough to make the cut, get reviewed, and merged is included in 2.3.  Otherwise, it waits in the pool for the 2013-03 release along with the rest of the un-merged community code.  

Yes.

> 
> 2. Alter the release schedule to better accommodate the GSOC schedule.

No.

> 
> 3. Shorten the beta period for 2.3 so GSOC projects have a better chance to make the cut.  (Note that pushing the Beta1 date back by any non-trivial amount effectively changes the release date and provides no guarantee GSOC code will still have time to pass through the review/testing/merging phases).

No.

Alexey Lazar
PALS
Information System Developer and Integrator
507-389-2907
http://www.mnpals.org/

On May 24, 2012, at 10:40 , Bill Erickson wrote:

> Hi all,
> 
> While discussing the proposed 2.3 release schedule (below) in the IRC dev meeting yesterday, Jeff pointed out that the GSOC code-complete deadline of Aug. 13 will likely put most/all of the GSOC code out of the running for inclusion in Evergreen 2.3 (using the proposed schedule).  The larger question is whether that should affect the Evergreen release schedule, this year and potentially in the future.  The smaller question is, if so, how should it affect the schedule?  I see a couple of options:
> 
> 1. Don't let it affect the schedule.  Any GSOC code that is completed early enough to make the cut, get reviewed, and merged is included in 2.3.  Otherwise, it waits in the pool for the 2013-03 release along with the rest of the un-merged community code.  
> 
> 2. Alter the release schedule to better accommodate the GSOC schedule.
> 
> 3. Shorten the beta period for 2.3 so GSOC projects have a better chance to make the cut.  (Note that pushing the Beta1 date back by any non-trivial amount effectively changes the release date and provides no guarantee GSOC code will still have time to pass through the review/testing/merging phases). 
> 
> Thoughts?
> 
> -b
> 
> ----------------------
> July 2  : Alpha 1 (as necessary, followed by A2, ...)
> Aug 1   : Beta 1 / feature freeze (as necessary, followed by B2, ...)
> Aug 31  : RC 1 (before US Labor Day holiday)
> Sept 19 : 2.3 General Release
> ----------------------
> 
> -- 
> Bill Erickson
> | Senior Software Developer
> | Equinox Software, Inc. / Your Library's Guide to Open Source
> | phone: 877-OPEN-ILS (673-6457)
> | email: erickson at esilibrary.com
> | web: http://esilibrary.com