apaku at gmx.de
Wed Mar 10 20:47:57 UTC 2010
On 10.03.10 21:12:30, Niko Sams wrote:
> On Wed, Mar 10, 2010 at 21:01, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 09.03.10 22:02:45, Niko Sams wrote:
> >> Hi,
> >> I just pushed kdevelop-plugin-rules, afaics they are in pretty good
> >> shape. (it's all very basic
> >> as no branches at all are involved)
> >> ...please review
> >> Andreas you said you want to convert python plugin, drop mine if you
> >> manage to import the
> >> parser properly.
> > I'm asking myself wether we should add plugins to that or not, i.e.
> > should the ruleset cover all playground kdev4 plugins? The reason I'm
> > asking is because that would mean converting stuff to git that is
> > possibly unmaintained and maybe should just be left in playground until
> > someone wants to pick it up and actually work on it. Would allow to drop
> > some old cruft that doesn't even compile anymore and makes the
> > kdevelop-project less cluttered.
> > For example the java and python plugin fall into the category of "hardly
> > maintained at all".
> You want to let them die in svn?
Yes, if they're not maintained they're dead anyway. No matter where they
life. If someone wants to resurrect one of them he should write the
conversion rules. Most of them are dead-easy (the exception would be
veritas/xtest and maybe valgrind as it has kde3 history).
> If we don't convert them their code is kind of hidden.
They'd be hidden anyway as they definetly don't belong into our kdevelop
project on gitorious. That one should only contain maintained
> And at least java gets picked up by harmish once in a while.
Well, yeah maybe thats ok.
> Oh - and I didn't write rules all plugins - just for the actively
> developed ones and the bigger ones.
I know, I was about to start to add automake when I had second thoughts
about it. I mean writing the rules is not a big deal - at least until I
hit something hard to resolve - but they should at least be in a
separate file (kdevelop-unmaintained-plugins-rules or so) so when
someone uses kdevelop+kdevelop-plugins rules he gets exactly what we
want in the kdevelop project and we don't need to document that
"afterwards we erased x,y and z repos as they were unmaintained".
You will not be elected to public office this year.
More information about the KDevelop-devel