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. > > 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
