On Monday, April 22, 2013 16:34:44 Kevin Krammer wrote: > On Monday, 2013-04-22, Sebastian Kügler wrote: > > On Thursday, April 18, 2013 16:28:45 Thomas Pfeiffer wrote: > > > Redoing the entire Kmail Touch UI in QML would definitely be too big a > > > scope for a GSoC project. What I want to have in the end is something > > > which shows the path ahead and can be built upon. > > > > On that note, I think it would be best to do the GSoC as small mergable > > steps, that can go in one for one. As most of the code is already done in > > QML, a ton of small patches that go into master one for one would probably > > be nicer than to create one big branch that has to be merged at some scary > > point in time. > > > > This is of course mostly up to Kevin, I guess, as he'll likely be > > reviewing > > most of the code, I just wanted to chime in in case it hasn't been thought > > of. > > The problem with that approach usually is that master gets frozen during > the GSoC period. > While we could probably make an exception for code that goes into > kdepim/mobile (I don't think we official release that), some changes could > affect even kdepimlibs and we certainly don't want to risk master branch > there. > > Suggestions welcome though
Idea: The "go in" doesn't have to be master, while master is frozen, the patches could get "reviewed into" another branch, which gets merged whenever master is unfrozen. The reason why I propose this is because I think it could become quite the monster project, that will take very long to stabilize and achieve feature parity again. A "kernel style" development process usually prevents that from happening quite effectively. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active