What's missing for 4.0

[Aleix Pol]

On Thu, Sep 17, 2009 at 6:45 AM, Andreas Pakulat <apaku at gmx.de> wrote:

> 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...
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

Well of course we need to plan and to do it well if you wish. It's free
software anyway, so the quality of our release depends on our willing as a
community. And anyway, I think it's ubuntu that they're already packaging
kdevelop4 as a released application, people needs KDevelop 4.

About the unmaintained stuff we can always wait right before the release and
then decide, it's an easy task to remove code :P.

I don't think the week of beta cycle is that much relevant, we've been
releasing beta's for months already.

Cheers!
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090921/a0996c4f/attachment.html>