What's missing for 4.0

[Andreas Pakulat]

On 16.09.09 22:25:15, Aleix Pol wrote:
> On Wed, Sep 16, 2009 at 10:06 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> > On 16.09.09 16:08:21, David Nolden wrote:
> > > Once again, I think it would be good to re-evaluate what features we need
> > to
> > > implement before we can release KDevelop 4.0.
> >
> > I've tried to tag things in bugzilla with Target 1.0.0 and 4.0.0
> > respectively, would be good to go over that list and check what might be
> > missing or what might be possible to drop.
> >
> > I haven't been able to go through the wishes again (as I did for bugs
> > recently) though.
> >
> > > So, the stuff that I think we need:
> > > - User friendly session management ("Close Session" instead of "Close All
> > > Projects", etc.)
> > > - A project-model selection mechanism (the dolphin stuff) that is merged
> > with
> > > the build-set, has a default-selection based on the currently open file,
> > and
> > > is used used as default for running/debugging
> > >
> > > And of course massive bug fixing (including the debugger).
> > >
> > > What's your list?
> >
> > I don't really know. I guess I'm using kdevelop too little.
> > One thing we definetly need - IMHO - is better integration between
> > project tree and vcs support (deleting a folder should delete it from
> > the VCS, adding a file to vcs should add it to the project). Another
> > vcs-related thing is being able to checkout a project from a repository,
> > possibly with a repo-browser-toolview.
> >
> > Another item is the grepview, it works, but it doesn't play well
> > together with projects. I don't have a clear plan on that though.
> >
> > Providing EditorContext for the editor context menu so vcs actions are
> > in it (Or does that work already?) and more importantly provide a
> > FileContext for the filemanager so we get a fully-loaded context menu
> > there.
> >
> > Another thing we have to decide is what to do about mercurial and git
> > support. I know mercurial got some love a few months ago, but I have no
> > idea what its state really is. I do know that git's state is pretty bad
> > and I also know that if I'd work on it we'd need another 3-5 months to
> > finish up as I'd definetly want to rewrite the code in parts.
> >
> > Then there's documentview, coverage, the whole veritas/xtest stuff,
> > valgrind and cvs. I never tried cvs and I think its a plugin that should
> > rather be in extragear - who uses cvs these days anyway ;) valgrind
> > plain doesn't work (AFAIK) and only the memcheck is properly supported.
> > veritas/xtest is unmaintained since almost a year, its hard to use and
> > IMHO clear candidate for removal. Same with coverage I think. Leaves
> > documentview, it works and has only few (if any) bugs AFAIK, but should
> > move to the platform IMHO.
> >
> > Thats about it. I think spicing up grepview would take 1 full weekend,
> > the context-menu-stuff only a day at most. The vcs stuff is a bit more,
> > probably doable in 2-3 weekends (features, not fixing up bugs found
> > along the way ;)
> >
> > I'd also like to point out that I think we'll need about 3 months of
> > feature freeze for bugfixing. There's already quite a pile of bugreports
> > and not all of them are so easy to fix. So I don't think a release this
> > year is very probable, rather january next year. This means we could aim
> > at releasing with KDE 4.4 (and potentially even requiring it if there
> > are important features/bugfixes to use).
> 
> Even if I agree that there are still missing features that we all would love
> to have, I think that since we're releasing a 4.0 version we can go without
> it. Actually we desperately need some new release, we don't want people
> using 3.* anymore.
> 
> I'd propose to follow the KDE 4.4 schedule (for freezing and so on, so that
> we can have translations and everything).

That (see http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule )
means a Soft feature freeze in about 1 month and a hard feature freeze
in not even 2 months. We can try that, but I'm unsure wether we can make
it. Additionally that means we only have one month and a week of beta
cycle (i.e. normal bugfixing), IMHO thats far too little for us.

And if we want to do that, we definetly need to decide about the
more-or-less unmaintained plugins. I'd like to release only with stuff
that has somebody who's willing to work on fixing the bugs in it.

Andreas
 
-- 
So you're back... about time...