On Tue, 01 Dec 2015 16:06:32 -0300 "Ignacio R. Morelle" <shadowm2...@gmail.com> wrote:
> Additionally, I've been considering moving us to a time-based release > schedule for development and maintenance releases, in order to keep a > constant stream of features and bug fixes coming to UMC creators > instead of piling it all up at once like we've done thus far. Under > the new scheme: > > * A new maintenance release from the current stable branch would be > tagged every two months, on the third Friday 00:00 UTC; meaning that > there would be an automatic string freeze every month starting from > the second Thursday 00:00 UTC. > * A new development release would be tagged every month, on the > first Friday 00:00 UTC, except for betas and RCs for the next stable > series, which would come every two weeks instead. > > Of course, this plan would require some degree of commitment from our > mainline packagers (loonycyborg (Windows) and ancestral (OS X)), and > I don't know yet whether this is feasible for them. Developers would > also have to commit to not pushing incomplete or broken features that > would affect shippability of the next development release, or at the > very least making it possible to easily disable > them at the last minute if time runs out. I don't see much point in timed releases honestly. However such schedule would be feasible for me, my only worry is that releases with little amount of changes would result and it will be more work for you to ascertain shippability every month for 1 or 2 branches. > And because we can't have infinite development releases forever, this > plan will also require us to put a list of features together *NOW* in > advance, including items which should be completed before a > prospective feature freeze for 1.14. I've made a page on the wiki > with a tentative list: > > http://wiki.wesnoth.org/DevelopmentRoadmap > > ... which also happens to include a tentative freeze date, August > 2016. There is a specific reason I chose this, which is the next > Debian stable freeze being on December 5 2016. Sounds good to me. I might add some items there but need to think about this more. > > An important point that needs to be settled ASAP is whether we'll > participate in next year's GSoC. Mentoring organization applications > will be accepted from February 8 to February 19, so we must have an > action plan ready before then. > > https://developers.google.com/open-source/gsoc/timeline > > In particular, we will need project ideas, mentors, and > administrators. I can't really dedicate time to GSoC myself, so the > GSoC admin will have to be someone else entirely (Ivanovic?). > Likewise, I won't be able to volunteer to be a mentor since that > would literally kill me. > > Of course, we can also decide to not participate in GSoC, which would > make things easier for everyone, but at the cost of a precious missed > opportunity. I could consider being a mentor, but being admin would be too much for me I think. _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
