On Friday, April 10, 2015 06:22:50 AM xor wrote: > > 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. >
Doh, I proof-read my mail thrice, yet it still took only 3 seconds after I sent it until a better way of saying the above came to my mind - sorry: Working on packaging aims to attract more new developers. However, there is no use in attracting developers if after we have caught their attention they then cannot actually work on the code because it is undocumented. Thus, documentation should be done *before* stirring up attention by packaging :) Maybe it might make sense to combine my "20% of the time for packaging" proposal with sticking packaging somewhere in the sequential order I had proposed for documentation: > 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. How about this: After step 2 is finished, 40% of toad's time could be used on packaging in parallel to the remaining documentation steps. -------------- 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/f92b0594/attachment.sig>
