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

Reply via email to