On Monday, 2013-04-22, Sebastian Kügler wrote: > On Monday, April 22, 2013 16:34:44 Kevin Krammer wrote: > > On Monday, 2013-04-22, Sebastian Kügler wrote:
> > > 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. Yeah, it is unfortunate that remote branches can not be rebased like local branches which effectively makes all changes in the branch look like a patch set on top of master. I'll need to check if there is a git workflow that gets close to that. > 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. My expectation is that most of the work will be separated by directory structure, i.e. not a lot of changes to code shared with the widget based applications. The mobile UI is currently not part of the standard build of kdepim, so any changes there, even in master, would not affect SC release parts. So changes there could potentially be pushed to master directly and then merged into a development branch that only needs to be created if there are actually changes to somewhere else in kdepim. Expected changes in kdepimlibs are more likely to be of the kind of adding Q_PROPERTY for existing setter/getter/signal tuples, which I think we can do even after feature hardfreeze if properly reviewed. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Active mailing list [email protected] https://mail.kde.org/mailman/listinfo/active
