Any idea when these payments might be processed? On Monday, October 3, 2016 at 10:11:32 AM UTC+1, Niall Douglas wrote: > > Apologies for the delay on sending this until after CppCon. The cause is > that one of the students did not perform much work during the second half, > and neither myself nor his mentor nor Bryce had the spare time to properly > deal with that situation until after CppCon, so I kicked the can down the > road by giving him an extension. Now we have some free time back we'll get > on with doing something, specifically that I have asked Bryce to > impartially review the student's work and compare that to the work plan > outlined at the beginning. > > That leaves the reports for the other two students who have been kept > waiting for their final payment for a month longer than they should. > > > > *Boost.Compute, Jakub Szuppe* > > Detailed report: > https://docs.google.com/document/d/1_z9lkDiIVBJ-a-oc-po2QrkNjf4Gf-Eb9lDb15gr7m8/edit?usp=sharing > > Mentor is very pleased with the work done this summer. > > > > Boost.Http, Vinícius dos Santos Oliveira > > > - Mini parser were introduced. They're stateless and simplify the > code. > > They can also be used independently in case you don't need a full > parser. > > - Real time was spent testing the abstractions to prevent errors. Good > > test cases, bad test cases, lots of them, new tests that would > simulate > > network fragmented bytes (one of the test binaries was starting to > get more > > than 30 minutes to compile under GCC Debug and I had to split it into > > smaller tests), enabling the sanitizer tests. Still need to add fuzz > > testing, but this will be to the future. > > - I've integrated the parser into Boost.Http message framework (which > > immediately benefited the parser with already existing tests) and > Tufão > > project (an active and not new project which already has some users > and > > became beta testers for us in the wild). > > - Client parser was finished. > > - Commits to make the parser more liberal in respect with what it > > accepts (the robustness principle). > > - Some refactors. > > Mentor reports that student initially went down route which was unwise and > disregarded mentor's advice. This caused some frustration for the mentor. > However, a while in student realised why mentor's advice was correct and he > replaced earlier route with correct route. This introduced a fair bit of > delay and caused original work plan to be missed by a fair chunk, however > when evaluating the whole summer's improvement mentor is pleased with the > overall outcome and recommends a pass. > > I personally would like to add that I've been watching this project for > some years and the student consistently works hard over the past three > years I've been watching. I have generally been impressed. Ignoring advice > from one's elders and realising the consequences is an important part of > the development of any engineer, especially as occasionally the student is > right and the elders are wrong. Most of the time, of course, it's the other > way round, but that's one of the most valuable parts of a mentor-mentee > relationship, and the best lessons you learn are generally from your > mistakes. > > > I would ask the steering committee to release the final payment for the > above students and mentor Kyle (Bjorn isn't accepting his payment). They've > waited long enough. > > Niall > >
-- You received this message because you are subscribed to the Google Groups "Boost Steering Committee" group. To unsubscribe from this group and stop receiving emails from it, send an email to boost-steering+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.