To freeze or not to freeze?

Milian Wolff mail at milianw.de
Sat Jan 16 21:48:01 UTC 2010


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).
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100116/23821a1f/attachment.sig>


More information about the KDevelop-devel mailing list