Project layout on

Andreas Pakulat apaku at
Mon Mar 29 22:10:51 UTC 2010

On 29.03.10 22:44:07, Niko Sams wrote:
> On Tue, Mar 2, 2010 at 02:48, Alexander Dymo <alexander.dymo at> wrote:
> >> Even if we don't fully support the plugins, it's good to have them in a
> >> central place so we have an overview what exists, and so that developers
> >>  who are interested in working (and collaborating) on them can do it
> >>  easily.
> > Right, but you don't need to look at the list of plugins. You'd find out about
> > new plugins via blogs/mailinglists anyways. After that you don't need a
> > playground, you just clone the repo and work together. And it's still hosted
> > by the author.
> >
> > Also, with gitorious you can follow people via rss, so you'll always know when
> > they're up on something.
> >
> > For example, if I started Ruby support in git, I'd create my own repository.
> > Anyone interested would pull directly from me and push to my repo. I wouldn't
> > need a playground for that.
> >
> >> We're anyway not enough to 'fully' support every (even working) plugin. How
> >>  do you want to manage the point when a plugin becomes "supported" and when
> >>  it becomes "unmaintained" again?
> > Maybe push changes back to author's repository and remove it from kdevelop
> > project? (dunno about privileges...)
> >
> Moving a repository from one project to another will cause problems i think:
> - push log gets lost (not so important)
> - merge requests and comments on them get lost

Do these really get lost, or do they simply stick with the old project?

> - comments on commits get lost

I'm not sure how useful these comments are, it does look like a
post-commit-review feature and as such comments older than X days/weeks
are not useful. If a comment raises a problem it should be dealt with,
in particular before moving the repo to another project.

> - users of the plugin need to be told about the move

Hmm, I'm not sure that is a real problem, or rather that its any
different from moving from playground to extragear/sdk/.

> Having a project per plugin no matter what state it is wouldn't have this issue.
> But that would consequently mean one project per repository.
> This layout would have greater flexibility but how do we group together
> the maintained plugins? Is a kdevelop-developers Team enough for that?

For gitorious the team-thing may be enough. Another question is what
happens when we want to integrate a plugin into the
kdevelop/kdevplatform repo. Technically I think its possible (I'm not
100% sure though), but this again looses merge-requests and everything

IMHO we should have a KDevelop project containing kdevelop, quanta,
kdevelop-pg-qt and the plugins from extragear/sdk at the point of
moving (yes I've changed my mind about kdevelop quanta splitting again).
Everything else is in playground and should be moved on a case-by-case
basis and get its own project.

A plugin will stay in its own project until we decide to have inside of
KDevelop itself (or Quanta or KDevPlatform) at which point its
acceptable to loose comments and merge-requests.

Plugins can also move out of kdevplatform/kdevelop repo into a separate
repo and then should go into their own project too.


Don't tell any big lies today.  Small ones can be just as effective.

More information about the KDevelop-devel mailing list