Moving kdevelop4-custom-buildsystem to g.k.o
apaku at gmx.de
Fri Nov 26 15:08:24 UTC 2010
On 26.11.10 14:29:45, Milian Wolff wrote:
> Andreas Pakulat, 26.11.2010:
> > On 25.11.10 21:01:21, David Nolden wrote:
> > > 2010/11/25 Milian Wolff <mail at milianw.de>:
> > > > David Nolden, 25.11.2010:
> > > >> 2010/11/23 Milian Wolff <mail at milianw.de>:
> > > >> > Imo all of this should be met for a plugin in the "plugins" folder:
> > > >> >
> > > >> > a) active maintainer who cares about bug fixes etc.
> > > >> > b) a first release, since that makes it clear that the maintainer is
> > > >> > confident it is in a "production ready" state
> > > >>
> > > >> c) stable, meet some quality standards (we should release stuff that
> > > >> works, not stuff that _might_ work)
> > > >>
> > > >> Or alternatively, the plugin should be important enough to be
> > > >> considered a crucial part of the IDE. What does this plugin do?
> > > >
> > > > Hehe, I find that one quite funny. What do you mean with "stable"? Who
> > > > decides that? And why must it be stable to be in it's own git repo (we
> > > > are not talking about merging it into either kdevelop or kdevplatform
> > > > repository here, are we?).
> > > >
> > > > It's the maintainer who is responsible for that plugin, if he releases
> > > > it and it's utter crap, people will note that and report it to him.
> > >
> > > Sorry, I'm talking about merging it into KDevelop/KDevplatform of
> > > course. Every somewhat maintained plugin should ideally be somewhere
> > > in our git repository.
> > While I'm willing to maintain it for the foreseeable future, I'm not
> > using it as much as I'd like (though the next few weeks might be
> > changing things again). Hence I'm not sure about moving it to kdevelop
> > (kdevplatform would be wrong IMHO as its of no use to Quanta for
> > example). I'll leave that decision to the community, but I'd like to
> > make clear that I currently don't have any plans for new features but
> > will be fixing any bugs that anybody finds (there's no b.k.o entry yet,
> > will do that once it moved).
> Since you told me quite often that it's stable and since it reuses the generic
> manager which is of course maintained by me, I'd say +1 from me. I just wonder
> whether we should ship it with 4.2, I'd be more confident with 4.3.
As I said, I'd rather not move into kdevelop at this point anyway. I'm
totally fine with it being available under plugins and doing a release
before it moves there (I'll try to do that this weekend). I can just as
well do a release for KDevelop 4.2 around the time when you're releasing
that into the wild. I probably won't do more than a single beta and maybe
one rc though before that.
> And I'll forward bugs to you of course, this is btw. my evil plan to get you
> back to hack on KDevelop :P
I think once its released I should open a bugzilla component in kdevelop
for it, even if its not part of the git repository. So you'll be spared
from forwading reports to me :)
You will be Told about it Tomorrow. Go Home and Prepare Thyself.
More information about the KDevelop-devel