2010/9/7 Maciej Mrozowski <reave...@gmail.com>: > Thanks for investigation! > > I'd like to address some points, actually the one that monolithic layout > breaks current application life cycle/workflow. > > It doesn't have to. > Provided we forget about extragear or playground being actual repositories. If > said places - playground, extragear, kdereview (or review) - are implemented > as branches of corresponding ${module}, forward changing state of particular > application is just merging between branches. > > Advantages: > > - moving forward (from playground->review, extragear->review, review->master) > is easy, efficient, and preserves history (if it's considered advantage, I > understand sometimes development history from playground for instance may not > be welcome when app is moved to master)
Even in the monolithic layout, the plan wasn't to have an extragear, playground or review repo. That part of the sysadmin analysis was a bit of a strawman. These loose groupings of slightly-related projects were never a real concern. Having a out-of-git solution like Redmine to provide organization makes more sense. Ian _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest