Hello On Tue, Apr 21, 2015 at 12:14 AM, Stefan Schmidt <[email protected]> wrote:
> Hello. > > On 20/04/15 14:53, Daniel Juyung Seo wrote: > > On Mon, Apr 20, 2015 at 9:25 PM, Tom Hacohen <[email protected]> > wrote: > > > >> On 20/04/15 13:15, Stefan Schmidt wrote: > >>> Hello. > >>> > >>> 1.14 is one a good way now an it is about time to discuss the schedule > >> for 1.15 > >>> Tom approached me with a suggestion to ease the predictability of our > >> release dates. > >>> Instead of doing a schedule being aligned with the 12 weeks he > suggested > >> that we use the first Monday of a month every three month. For us that > >> would mean: > >>> First Monday of August: 1.15 > >>> First Monday of November: 1.16 > >>> First Monday of February: 1.17 > >>> First Monday of Mai: 1.18 > >>> First Monday of August: 1.19 > >> Yup, and the freeze starting the first Monday the month before. This > >> way, we don't have to think and look up when freeze starts/ends and when > >> the release is at, we just know (at least the ballpark). This also lets > >> projects that have more long term planning than what we do, reliably be > >> able to predict our releases way ahead. > >> > >> > > Very good idea, tasn. In this way, we can easily guess the next release > > date. > > > > > >>> ... > >>> > >>> This means we are no longer having the fixed 8+4 weeks schedule instead > >> the merge window would grow or shrink based on the months lengths. I > would > >> keep the stabilization phase at the last 4 weeks as we are doing now. > >> > >> The variation in length is not that significant. > >> > >> > > Same here. If it's not like 2~3 weeks difference, the variation in length > > should be acceptable. > > > > > >>> Based on this a proposal looks like this: (9+4 weeks) > >>> > >>> 2015-05-04 Merge window for 1.15 opens > >>> 2015-06-22 Notice about soon ending merge window > >>> 2015-07-06 Merge window is over. > >>> > >>> * Only bug fixes from this point > >>> * Alpha release tarball > >>> * Four weeks stabilization phase starts > >>> > >>> 2015-07-13 Beta1 release tarball > >>> > >>> * Only critical fixes from this point > >>> > >>> 2015-07-20 Beta2 release tarball > >>> 2015-07-27 Beta3 release tarball > >>> 2015-08-03 EFL 1.15 is Out (First Monday in August) > >>> > >>> What do you folks think about the idea? > >>> > >>> The second topic which makes 1.15 different from other releases is that > >> July will be a problematic time for 1.15 as I will be offline for 3 > weeks > >> in July. This raises the question how we are going to handle this. It > will > >> be the first three weeks in July which means I would be back for the > final > >> release but would miss most of the stabilization phase. > >>> Options I see for this: > >>> 1) Extend the merge window for 1.15 about three weeks so we would start > >> stabilization once I'm back > >>> 2) Count down 1.5 so we finish by end of June > >>> 3) Find someone who is willing to handle merge window close, alpha and > >> beta stuff. > >> > >> The last one for sure. You shouldn't be pressured to change your life > >> according to E releases, and e releases shouldn't change according to > >> your life. > >> > >> > > +1 for #3. > > Tasn already said what I wanted to say. > > You've done a good job so far but you shouldn't be pressured. > > > > I would like to volunteer at least for elementary if you need a help for > > last moment bug fix, testing, news update, tarball, and etc. > > Thanks for the offer! > > If possible I would like to someone taking care of all 4 libs together > so there is no effort in coordination and communication. > Most of it is automated already with an ugly shell script: > https://git.enlightenment.org/admin/release-management.git/tree/release.sh > > The procedure itself is outlined here: > https://phab.enlightenment.org/w/release_procedure/ > > That sounds cool. I would like to volunteer for the release job while you're away. With a couple of times experience, when I could do the release by myself at some point then you can go on holidays freely. That's the benefit when you have multiple release managers :) I expect managing release takes time even there are scripts and written process documentation. (thanks for your effort) But this would be a good start. Let's rock. > I would walk the person through my process and also would do one stable > update release with him/her to get the hang on it. > > I'm also back for the final release so if something does not work as > planned it would be only the alpha and beta tarballs. :) > > Daniel, if you want to handle all 4 let me know. If not I would first > search for someone who would handle all of them and come back to you if > they are splitted up in the end. > > regards > Stefan Schmidt > > > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
