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: [email protected] > | web: http://esilibrary.com
