Project layout on gitorious.org

[Niko Sams]

On Tue, Mar 2, 2010 at 02:48, Alexander Dymo <alexander.dymo at gmail.com> 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
- comments on commits get lost
- users of the plugin need to be told about the move

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?

Niko