On 25/02/14 16:20, Daniel Juyung Seo wrote: > On Wed, Feb 26, 2014 at 1:03 AM, Tom Hacohen <tom.haco...@samsung.com>wrote: > >> Hey, >> >> On 25/02/14 14:39, Stefan Schmidt wrote: >>> Hello. >>> >>> It just happened. EFL 1.9 is Out. >>> >>> Time to look forward and decide on how we want to handle 1.10. >>> >>> 1.9 went well enough for me to not burn me out which means I would be >>> willing to do 1.10 as well. Given that nobody better suited stands up >>> for it or you guys decide that I did a bad job. >> >> Only time will tell if you've done well. >> >>> >>> For whomever will manage 1.10 I have a proposed schedule: >>> >>> === Schedule === >>> 2014-02-25 EFL release 1.9 / Merge window for 1.10 opens >>> 2014-03-20 Notice about soon ending first merge window >>> 2014-03-24 First merge window is over. >>> * One week stabilization phase starts >>> 2014-03-31 Second merge window opens >>> 2014-04-24 Notice about soon ending second merge window >>> 2014-04-28 Second merge window is over. >>> * Only bug fixes from this point >>> * Alpha release tarball >>> * Three weeks stabilization phase starts >>> 2014-05-05 Beta1 release tarball >>> * Only critical fixes from this point >>> 2014-05-12 Beta2 release tarball >>> 2014-05-19 EFL 1.10 is Out >>> >>> Two things have changed to what we had with 1.9 before. The first >>> stabilization week was cut down to one week and this gained week was >>> added at the end. Some people, including me, have the feeling that it >>> would help us to iron out the bugs before the release. >>> >>> The second thign is that I'm hopefully clearer with the dates this >>> time. I heard people had trouble with them. :) >> >> Schedule is good, dates should be defined either using wiki timers (like >> you've done for the release), UTC, or 24hr line (last country to change >> the date). >> >>> >>> One thing Tom suggested is that we create phab counters for all events >>> and once they are down to 0 its over. >> >> Oh, oops, you already mentioned that. :) >> >>> >>> Besides that I found the schedule and procedures to work ok for most >>> cases. The only thing that really bothered me at the end has been the >>> preparation of the NEWS files and release notes. What bothered me most >>> was the situation that the developer would be way better suited to >>> write a blurb about their masterpiece. Sadly almost nobody did it. :) >>> >>> I would strongly vote for a way to autogenerate at least a good list >>> of entries for the NEWS files. One has to go over it by hand anyway >>> but having tags or such in the summary would help scripts. Tom already >>> made some suggestions about this in another thread. I just wanted to >>> express my support for it. Its kind of a must from my view during the >>> 1.10 cycle. >> >> Just to reiterate my suggestions here: @feature for new features, @bug >> for bugs that should be backported. Those tags should be in the commit >> message, but not the summary line (which should be regarded as a NEWS >> entry. As clear, as expressive, and etc.). >> > > Hi Tom. > @bug or @fix? > > I have some commits to push now. I will try to use @feature and @bug/fix > for the commit message. (not in the summary line) > Let's try!
Could do @fix, doesn't really matter. Just needs to be decided upon. -- Tom. ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
