Project layout on gitorious.org
apaku at gmx.de
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 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
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