[GSoC 2015] C++ refactoring

[Maciej Poleski]

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.
> 
> Aleix

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.

Thanks again

Best Regards
Maciej Poleski