To freeze or not to freeze?

[Aleix Pol]

On Sat, Jan 16, 2010 at 10:48 PM, Milian Wolff <mail at milianw.de> wrote:

> Andreas Pakulat, 16.01.2010:
> > On 16.01.10 22:19:44, David Nolden wrote:
> > > Am Samstag 16 Januar 2010 20:57:14 schrieb Andreas Pakulat:
> > > > So apparently people are happy with freezing. That would mean
> complete
> > > > feature freeze in a bit above 2 weeks (if my calendar is correct).
> I'll
> > > > announce it on monday on the list (unless someone objects)
> > >
> > > A total feature freeze in 2 weeks is ok, but only if UI tweaks, like
> > > making stuff more consistent or renaming it, are not put into the
> > > "feature" category.
> >
> > Either we have a feature freeze, which means no new features whatsoever
> > only bugfixes or we don't do it yet. We can certainly delay the
> > string-freeze until after the sprint.
>
> What about we continue as we are doing these days? We all polish and fix
> what
> we can and no one gets the idea to push some fancy new stuff in. I
> personally
> think that in the past weeks not a single new feature was implemented. All
> these things were just polishing of existing features. A tooltip here or a
> context menu there is - to me - not really something we should forbid
> during
> the sprint.
>
> > > Apart from that, there is 2 important mini-features I think that are
> > > still missing:
> > > - Path-specific source-formatter settings (you wanted to work on it
> this
> > > weekend, so might not be a problem)
> >
> > I might actually not get around to that, kinda sick over here
> > unfortunately :(
>
> Get well soon!
>
> > > - A blacklist for project-items, so we can finally get the "*~",
> ".bak",
> > > ".rej" etc. crap out of quickopen and the project tree.
> >
> > That just needs to be moved from the generic-manager into a utility
> > class that all managers can use. (I've pondered already quite some times
> > about basing the cmake manager on the generic one class-wise, but not
> > something for 1.0).
>
> Imo the GenericManager is only generic by name and the files it supports,
> not
> in it's Class architecture. Esp. the hoops it jumps to support remote files
> is
> something CMake should not bother with. Extract the features you need and
> put
> them into the BaseClass or a Utility, but don't make CMake extend the
> GenericManager (imo).
>
+1

Actually the shared code wouldn't be that much i think. But well, of course
we should share the most.


> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100116/fa08312b/attachment.html>