On 24/10/14 11:28, Daniel Kolesa wrote: > On Oct 24, 2014 10:42 AM, "Tom Hacohen" <tom.haco...@samsung.com> wrote: >> >> On 24/10/14 09:32, Daniel Kolesa wrote: >>> 2014-10-24 9:49 GMT+02:00 Stefan Schmidt <ste...@datenfreihafen.org>: >>> >>>> Hello. >>>> >>>> On 23/10/14 10:54, Daniel Juyung Seo wrote: >>>>> Hello >>>>> >>>>> Daniel Juyung Seo (SeoZ) >>>>> On Oct 23, 2014 12:23 AM, "Stefan Schmidt" <ste...@datenfreihafen.org> >>>>> wrote: >>>>>> Hello. >>>>>> >>>>>> On 12/10/14 16:40, Tom Hacohen wrote: >>>>>>> I think 4 weeks is too long, 3 weeks should suffice. >>>>> I agree with Tasn's idea. If I remember correctly, the main reason of >>>>> splitting the merge window was to avoid a long stopping of a > development >>>>> phase. >>>> >>>> I would actually like to see people stop developing and focusing on bug >>>> fixing and quality control at this time. >>>> >>>> If more people would do that 3 weeks would be fine. >>>>>> You would want to add this week to the merge window or cut the whole >>>>>> cycle down to 11 weeks? >>>>> How about 9 + 3 then? >>>>> >>>> This shifts the devlopment vs. stabilization ration from initial 2:1 to >>>> a 3:1. >>>> I'm skeptical if that is a good change. Especially if one consider that >>>> the number of bug reports are rising continuously. >>>> >>>> We need more people activly work on our problems in the stabilization. > I >>>> wrote a specific mail for that. alpha1 is out for a week now. How many >>>> of us had a look at the bugtracker, the API/ABI report or the remaining >>>> coverity issues? >>>> >>>> I'm fine with three weeks stabilization as long as I see enough > problems >>>> being tackled at that time. What I'm not fine with is to cut it down >>>> even further just so people can start sooner to brign in new > development. >>>> >>>> >>> While new development is where all the fun happens, I agree that QA is >>> extremely important. As such, I agree with your proposal of 8+4. IMHO if >>> new developments are to be made during freeze period people can work in >>> their own branches anyway. No need to cut down on testing period there. >> >> Then you have the problem that people's work diverges too much. It's not >> fun developing in branches. Furthermore, it sucks the fun out of the >> development, having to wait a shit-load of time until your features goes >> into core. > > IMHO not such a big issue - it's somewhat less convenient but there are > tools in Git to make it bearable.
Git makes it technologically possible, but 1. people won't do it. 2. You still have to know where to look (i.e source branches manually). > >> >> Another important thing is that if you force people to work in branches >> for their future development during the freeze period, they end up >> working in branches, which means they are not testing master anyway. You >> wanna find the sweet-spot, where people still use master and test it, >> while not slowing development for too long. > > The not testing master part is kinda solved by frequent rebasing, but yeah, > I guess... > >> >> Last but not least, while I'm all in favour of stability, I think this >> is a sacrifice worth making, and that we should focus on lowering the >> testing period as much as possible (by, for example, adding tests), >> rather than forcing development stagnation. >> >> -- >> Tom. >> >> >> > ------------------------------------------------------------------------------ >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > D5 > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
