On Thursday, April 09, 2015 09:27:32 PM Steve Dougherty wrote: > Google Summer of Code didn't work out for us, but maybe we can have a > Freenet Summer of Toad?
Toad should be always welcome! :) > If we go through with it we'd put a fundraising bar on the website and > count subsequent donations toward it. I highly appreciate the concept of a fundraising progress bar, similar to what Wikipedia does - good idea! Once we have this implemented, we can and should also use it once every year then. > What would we want to direct this development time toward? My opinion is > that more code / features is not what Fred needs most right now. Full ACK on not having him work on features. Semi-Non-ACK on what you suggested he should do, in-depth explanation below. First here's my idea what he should do: It seems to me that toad is still uncertain about what happens after his studies = whether he wants to continue his work for Freenet then. (Please correct me if I'm wrong!!). So the #1 effort while he can still do some work in his summer vacation should be to make it possible for someone else to continue his work if he really does leave (which I strongly hope he does not!). Thus, the primary goal should be to fully document the existing code he wrote. Practically speaking, I would say we do this: Considering that it is very difficult to say how long documenting everything will take, his work should be like an onion to allow some progress everywhere - first high level documentation, then low level, until time runs out. I suggest the following order, sorted descending from high to low level: 1. Write package-info JavaDoc for all packages (I think he actually did that already before he left for the first time) 2. Write class-level JavaDoc for all classes. 3. Write JavaDoc for all member variables of classes. 4. Write JavaDoc for all functions. 5. Write generic documentation and tutorials on the Wiki. Now I know that *full* JavaDoc for every class, member variable and function does sound quite extreme. But don't forget what we are: A mostly volunteer-driven project. Volunteers may come and go as they please, and they in fact do that very frequently, and thus such projects have the highest throughput of programmers in the whole industry. Therefore, full documentation should be mandatory to make it as easy as possible for new volunteers. (Notice: I am already trying to obey this at WOT and my fred pull requests as well. Feel free to notice me during review if anything is lacking JavaDoc) > I'd > like to ask that Matthew document plugin APIs I think you seem to be somewhat biased to plugin stuff. I think he should just document everything :) :| - As a plugin author, I can say that most work lies within plugins themselves, not within their interaction with fred. What fred does is highly complex, but what it spits out (= what plugins use) is simple: You request a key, it gives you a file. It isn't that difficult to understand. The stuff fred does under the hood however *is* very complex: Due to my recent work, I've counted all classes which are involved in fetching/inserting files, and they're at least 28 IIRC. And this is just the stuff which represents a file request/insert, not the stuff which deals with splitting files into chunks, adding redundancy, etc. And then there's also the whole universe of how Freenet itself, i.e. routing etc., works. Plugins are not involved at all in that, yet it is important to be documented for fred development to be possible. > and work on packaging: > things like splitting freenet-ext, making a Debian / Ubuntu package, and > maybe even creating an official distro package repo in Freenet. This is > because for those utilities that already exist, Freenet is pretty > effective, but I have seen many developers give up when they see the > lack of documentation, and the lack of packages makes it harder to > install and harder to depend on. There are unofficial packages for Arch > and Gentoo, and freenet-ext being monolithic makes packaging Freenet harder. Hmmm. I actually do agree that it might be a very good idea to finally resolve the situation of not having Debian packages. Personally, when looking for software for my Linux workstation, I have the following rule: "If something is not packaged, I will use something else. If people don't even bother to package software, it must suck." :( I think there is a high probability that this is the general behavior of Linux users :( Package-management is such a nice concept and great advantage of these operating systems. And most potential Freenet developers are probably Linux users: We have for a long time not even had a proper Windows installer because everyone was on Linux. However, it will not magically solve the documentation problem, and thus should be deferred. We should really first quit having a truck number of 1. Is someone else maybe willing to deal with part of what you suggested here? If not, I would say it should at most be allowed to take a minor percentage of toad's summer work. Perhaps 20% ? > If documentation is > completed it could get as far as developing improvements to the plugin > API. It is mandatory that any changes be backwards-compatible. NACK on plugin API improvement work: This should be done on demand as plugin authors actually need something. The plugins we have are still very primitive, so there is not much more they could need from fred. And it will probably take some time until plugins get more complex: WOT still slow = no use in having me work on the plugins based on it :( Also, my proposal of "documentation improvements mostly" is actually a foundation for plugin API improvements: Documented fred = plugin authors will understand how it works = they can improve the plugin API themselves as they need it. It is possibly better if plugin authors work on plugin API themselves anyway, they might know what they need better than fred developers. (Toad: Sorry if I am wrong with the assumption that you didn't do much plugin work yet. Please correct me if I'm wrong!) > Thoughts? General remaining thought: Thanks for pushing this! Funding is important, and toad is important :) If he wants to work for us during summer, thats nice, I appreciate it a lot :) Go toad! :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20150410/fa00e466/attachment.sig>
