On Thursday 16 Feb 2012 18:29:16 xor wrote: > On Thursday 16 February 2012 19:12:52 Florent Daigniere wrote: > > Hi! > > > > Should Freenet take part to Google Summer of Code 2012? > > Yes. > > > Is anyone motivated to mentor candidates? > > Yes. me. > > Project suggestion: > Have a student do NOTHING but reviewing FRED code from the entry point on. > He should JavaDoc everything which he reviews, fix any bugs which he spots > while doing it, and refactor unclean code. > Ideally, toad would mentor this student. > > IMHO this is CRITICAL for the survival of the project as a whole: > - Most code has only been reviewed by toad as he wrote most of it
True. > - It has little to no JavaDoc Stuff I wrote from scratch often has SOME javadoc. Of course it's never adequate docs. > - Its quality is questionable in quite a few places. True, both in old and new places. And where it does wierd things, we need to document exactly WHY it does those wierd things. To some degree this does happen e.g. in the client layer, but it's far from complete. > To be fair I should say > that I did not read much of FREDs code, but when I read some of it, I almost > always encountered functions which fill multiple screens and violate lots of > best practices of programming / software engineering. Sometimes the best practices are wrong. :) E.g. because of persistence issues, or because we don't need to worry about scalability in a particular function as we can bound the size of the structures. But the reason they are best practices is they are right most of the time, sure. And yes, big functions are bad. > - We see little effort of volunteers writing code for FRED which might be > caused by the poor readability / documentation. True, but chicken/egg problem - it would take an outsider a lot of work/long time to figure everything out, and a lot of questions etc, and if they tried to clean stuff up they'd need a lot of supervision. An insider probably has more important things to do. So ideally we'd want to quantify this - to what degree is ugly code a barrier for core contributions? > - We might need another / replacement full time programmer as toad is busy > with university Yes, we may. > - In general, FRED seems rather buggy right now, and reviewing might fix that. Yes, although fixing the bugs might be a more direct approach for most. :) > - The probability of toad or a volunteer suddenly doing a full review of fred > is very low, so we should try to get someone to do it by rewarding it with > money as a GSoC project No, I don't think this will work. GSoC coders are often not all that great, and even a great coder would have difficulty accomplishing a significant proportion of the task you are proposing in the limited period available. And they would need a lot of competent supervision - and if they're not really great the supervision workload is greater than the achieved output; this is the fundamental problem with GSoC: 1) it's less work to just write it yourself; 2) most people don't stay (but the few who do may make it all worthwhile). One other parameter is that we've used it to reward and integrate existing peripheral contributors who happen to be students; this is usually fairly successful. Having said that, documenting and unit testing some limited part of fred might be workable. > - I could go on and on about this, but I think I've made my point already. IF documentation is within the scope of GSoC. This is probably a standard question, look it up. Also, with or without Google, we have a donor who might be willing to fund somebody to build unit tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120216/4df58aec/attachment.pgp>
