[GSoC 2015] C++ refactoring
d82ks8djf82msd83hf8sc02lqb5gh5 at gmail.com
Thu Mar 26 21:49:14 UTC 2015
Dnia środa, 25 marca 2015 00:29:17 piszesz:
> On Tue, Mar 24, 2015 at 10:42 PM, Maciej Poleski
> <d82ks8djf82msd83hf8sc02lqb5gh5 at gmail.com> wrote:
> > Dnia poniedziałek, 23 marca 2015 01:53:19 Aleix Pol pisze:
> >> I like the proposal. You know what you want to achieve and why. That's
> >> good.
> >> Things:
> >> - GSoC finishes the 24th of August!
> > Even 21th. I thought I have the whole September...
> >> - Tests are part of the development, you won't spend time afterwards
> >> testing. Feel free to introduce a time slot in the beginning to set up
> >> a testing infrastructure though.
> > What does it mean "to set up a testing infrastructure"? Is it some kind of
> > "maintenance task" of CI server? Or some special approach which I should
> > invent to enable "exhaustive" testing of upcoming features.
> You'll have to unit test everything as you proceed, so maybe you want
> to work on the actual test, so that later on it's fast and easy to
> create tests that make sure the feature works.
> >> - I would cut on the complex and probably less useful operations. I
> >> would concentrate on those where you can give a clear use-case and
> >> polish the use-case.
> > I cut lot of functionality to fit in time... In general I resigned from
> > working with sets of declarations focusing on single "units". To some
> > extent missing features could be simulated by repeated application of
> > "single task" on consecutive declarations. It will not handle mutually
> > dependent units through.
> > It will be more like "strong base" rather than "fully fledged solution"
> > (at
> > least as GSoC time frame is concerned).
> My point of view is that "strong bases" don't work on GSoC. I prefer 2
> finished features that we can advertise than 5 future promises. It
> will also be better for you to show finished things afterwards when
> you explain what you did for a GSoC.
Big thanks for advices. This is slightly different approach to task than I
thought earlier, but it indeed makes sense. I will focus on "safer" approach,
which is to provide real features "now" rather than mighty "in future". It
will give us more predictable results.
More information about the KDevelop-devel