Re: [freenet-dev] Freenet 0.7.5 build 1346
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > - Better disconnection detection. We were thinking we are still connected > sometimes when we were in fact disconnected and receiving some early auth > packets but not the late ones (as with the above case). Having read that i was hoping that my problem of all piers disconnecting until Freenet is restarted would go away. Unfortunately it's still there. - Volodya - -- http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast "None of us are free until all of us are free."~ Mihail Bakunin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNV3UUAAoJENW9VI+wmYasfBkH/3eICXnDQ77812esCIRfzv4i ufU8ltaPGNTsmvwcWrmLsBLkiCvHBkS8H5rAjBhYLojVotwJafpG6UhNsBItRH0h LTLzJHyby+buKCaWAUDDuqRLgkIvXBR4szKCJ6hhGVtVOZdmLE5fWlk+vNfh3tgP CGRo0fw3o7jDGzIPsI7gkSQGrvkuKsVy7Z4VVECZri+f5i+tGMtOFi3H2GV68S16 ufKOsGGyJjEu/CPCMQGkic1uCkLwI6qUf7U8lQxmhJpKkByu1X3fG1nKmAUU65r/ 7rngi/5ycudXvOIvHOqrw2QlT+I0iNqSZyQ8kb70ozi4FnrSx58rU3ENwx5rWiI= =a967 -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project
I apologise for replying before I at least had a proper look at the website! This is in fact fascinating and there may well be things we can do together or at least inspiration we can draw from one another. Lets get detailed, technical, and concise, about what would be involved in Freenet working with Unhosted, as one of many options for transport etc. Sorry for the general waffle last time, it's worth reading though. The basic principle of Unhosted from a freenet-ish angle is: - Websites are static and therefore can be hosted absolutely anywhere. - The website is a (large?) javascript applet. The client trusts the author of the website, within reason. - Data is encrypted by the client. - Data is stored on a separate storage server. - CORS allows this (this requires relevant request headers) - The PKI sounds very strange! On Freenet we always pass the hashes of the pubkeys... :| Now, compare to Freenet: - Freenet is reasonably good at hosting static content. - It strips out javascript in order to preserve security. This happens at the fproxy level; if the app is trusted it could be whitelisted or something. - Data is stored by clients for themselves, which is easy on Freenet, or it is routed between clients via queues, which is somewhat harder: Because of spam problems, we need to announce identities and establish a web of trust between them, or at least that's how current stuff works; we could use CAPTCHAs or some similar scarcity mechanism directly on a per message basis, but once a relationship is established it is unnecessary, and there are serious worries about the long term viability of CAPTCHAs. - Your PKI sounds rather strange... We could probably provide a WoT-based lookup service and be API-compatible though... There are some interesting sandboxing options. The big difficulty preventing Freenet from allowing Javascript is not the difficulty of writing a javascript filter (although that is a hard problem it is a solvable problem); it is the difficulty of defining a safe API for it to call. Freenet only provides request and insert - fetch and put - but with that alone, a malicious app author can do a lot of mischief. I wonder if we could build a usable sandbox based on Unhosted principles, i.e. an app can download and upload data specific to its user, and can talk to other users. We could even provide a confirmation mechanism per-user for more paranoid users, which could smoothly integrate into the app's UI if we are really good, including CAPTCHA-based introductions ... h, there could be something in this ... might need API changes though, how do you deal with introductions now? Such principles may be valuable to Freenet even if we have to break compatibility with Unhosted... Thoughts? -- 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/20110212/2249f4dd/attachment.pgp>
[freenet-dev] [unhosted] Unhosted and Freenet Project
kind linked to resources, even if it is only a public key that was never used for anything else. For instance, in future Freenet will announce uploads via its chat system. Truly anonymous announcements are extremely difficult, given spam: It is far more efficient to create an identity and reuse it, gain trust for it etc. > > Unhosted is essentially in-browser. I heard of an in-browser anonymity > network called Veiled. Maybe they are more interesting to you than we are. It is in-browser yet it communicates between different nodes? I have heard of such things... Generally Freenet needs good uptime so in-browser doesn't work too well. Except on opennet, but even there low uptime means massive storage redundancy, which we don't really provide, and opennet is so easy to attack that I'm reluctant... Freenet in a java applet would be fun (how do you allow connections to other nodes??) and could get a huge audience, but it'd introduce a lot of new problems... > > Anyway, I'm available for whatever you need from me. > > Cheers! > Michiel > www.unhosted.org -- 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/20110212/025974e8/attachment.pgp>
[freenet-dev] Open Knowledge Foundation Distributed Storage Research Project
On Friday 14 Jan 2011 11:56:09 Alex Rollin wrote: > http://wiki.okfn.org/p/Distributed_Storage > > The group has chosen Tahoe for their grid, it appears. Does this help > with anything>? Here are their use cases: > > Use cases for Tahoe grid Academics generally dislike Freenet because not much is published since 2000 and it's generally too heuristic, not enough is provable, compared to classic DHTs. > > We get the same two features of backing up, and sychronising the new > stuff (not file diffs) to a different computer. > > case 1 > The whole repository of a particular type is all copied down into the > server. Tahoe is used as a backup and moving of the server's data. > Everything is available for processing across all of the data. The > server can add new files to the repository. > This case applies to undemocracy and parlparse because all the data is > needed in order to present users with statistical figures (eg > attendance rates in votes). > > case 2 > Files are served directly out of Tahoe through a server. The full > repository is not copied down. The server merely caches some files. > More useful for delivering the PDF documents or images where > statistical analysis are not always wanted. More broadly speaking, distributed backup and similar stuff generally needs reliability guarantees that Freenet can't provide. Also, look at their goals - performance is important, privacy is not. Until and unless Freenet shows that it is in fact possible to have really good performance while still having hard privacy, this is not an appropriate use case. One interesting factor is that we should have tools to probe data retrievability without having to bootstrap a new node, and to automatically maintain either your site or somebody else's. This is planned, or at least, there's a bug for it and it's been suggested many times. -- 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/20110212/6efa0102/attachment.pgp>
[freenet-dev] Solving the release policy problem for 0.8.0
bers? We have a rolling release in practice. The purpose of release numbers is publicity, and the purpose of publicity is 1) money and 2) growth in users (leading to 3) more developers). > > Anyway I'm not done yet, but my fingers hurt and my mind lost track.. So I'm > done for now... You can now start the flamb?... > > > > -Original Message- > From: devl-bounces at freenetproject.org [mailto:devl-bounces at > freenetproject.org] On Behalf Of Matthew Toseland > Sent: Monday, January 24, 2011 11:31 AM > To: devl at freenetproject.org; support at freenetproject.org > Subject: [freenet-dev] Solving the release policy problem for 0.8.0 > > oWe need a release, because: > 1) We haven't had one for quite some time. > 2) We will run out of money eventually, we cannot presume on Google's > generosity and even if we do they will want results. > 3) We need more users. > 4) We have something of a publicity opportunity resulting from various > political developments. > > However: > - I agreed (foolishly) to a deadline that I am now 100% confident is not > achievable (31st jan for feature complete alpha). > - The features list that I had expected when I agreed to the deadline was > significantly different to what I think is needed now. > - The network has serious problems. This is partly because of my efforts on > new load management, which have tended to be fairly disruptive. It is partly > because of the way that those changes have been deployed. > - There has been a tendency to accumulate serious bugs and brush them aside > because they are not related to the first goal. This will cost us users and > probably developers. > - Likewise there are workflow issues related to deadlines and developers. > - This has all resulted in major stresses on me which also may cost us users > and developers. > > Clearly we need to work towards a release. IMHO the first thing to do is: > 1) Define a path features-wise, or a set of requirements that drive features, > and > 2) Make it clear how to deal with things that are not on that path. > 3) Work towards a point where we can focus on debugging less serious (not > structural) issues, which will involve a reasonably clear deadline only > modifiable if very bad things turn up that we didn't realise. > > Second point first: I will revoke most people's git rights to simplify > release management. If you are working on stuff that isn't directly relevant > to the release, please continue to work on it, but do so on a branch, e.g. on > a github fork. If it is stable, small, and non-disruptive there may be points > at which it can be considered. > > So what do we need for 0.8.0? I have created an ietherpad document: > http://ietherpad.com/z1kgs1fmSg > > I appreciate we have had such discussions a lot over the last 6 months. And > this has been my fault as much as anyone's. Sorry folks... > > My proposal is that the list of features and goals in the above shall guide > my behaviour and what gets merged vs postponed from volunteer efforts: > 1) I will not code on stuff that doesn't support the release. > 2) Volunteer efforts that don't support the release should be kept separate > until after the release. > > Because I have to casually review everything in fred anyway, it is > significantly easier for me if I merge stuff. I don't believe I will become a > bottleneck, or will end up using most of my time reviewing stuff, with the > current level of volunteer contributions. I will therefore revoke everyone > else's (or almost everyone else's) commit rights to the fred-staging > repository. Or maybe we should just have a separate branch for out-of-scope > stuff? Other repos can and should be owned by other people, although I > casually review all released code (e.g. Freetalk). Of course on other > projects I still ultimately decide what gets released e.g. when to deploy the > new freenet-ext.jar. > ___ > Devl mailing list > Devl at freenetproject.org > http://freenetproject.org/cgi-bin/mailman/listinfo/devl -- 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/20110212/7a4fb65b/attachment.pgp>
[freenet-dev] Solving the release policy problem for 0.8.0
On Monday 24 Jan 2011 23:44:44 Ian Clarke wrote: > On Mon, Jan 24, 2011 at 12:34 PM, David ?Bombe? Roden < > bombe at pterodactylus.net> wrote: > > > I have recently started using the branching model suggested by Vincent > > Driessen in http://nvie.com/posts/a-successful-git-branching-model/. At > > first > > the amount of branches that are created seem overwhelming but after a short > > time the benefits of having features cleanly separated before merging them > > outweigh the added complexity of the graph in gitk by far. > > > I'm all for doing things in ways that have been proven successful by others. > The current approach which involves a variety of independent repositories > does seem fairly peculiar. Independant repositories for each subproject is sensible and normal practice. Now, to examine the page above: It is interesting that he endorses a push-based model, where many devs have push rights. This mostly works but it is tricky when a big change gets pushed and then undone in review. Generally the view is that it's better to just have many repo's and pull requests. Although right now quite a lot of people still have push rights. Some devs openly prefer posting pull requests. New devs are generally encouraged to branch via github and post pull requests. This certainly makes life easier for me with the current release process. If we did choose to continue with a many-push model, we'd probably want to set some rules about what branches you can push to. He uses "master" for the stable release, and "develop" for the latest pushed stuff. We use master on the stable repository for the stable release, and "master" on staging for the latest pushed stuff. So far so similar. Having said that, lately we use release branches a lot, which can diverge quite a bit from master. Feature branches I use in origin for larger changes, and a few other people do. Devs who post pull requests almost universally use feature branches. Feature branches are good, IMHO better than developing directly on master in most cases. Arguably they should be used for even relatively small features. Using the --no-ff option when merging a feature branch is a good idea. Release branchs are a good idea. At the moment I use release branches whenever I need to release some small part of what is on master. Wider use may make sense. I only update the version number at the last minute, which IMHO is better for our use as things may happen that make the branch planned to be a release actually into the following release. These are often, but by no means always, actually hotfix branches by his model. And of course we use signed tags for all releases, and for prereleases too. -- 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/20110212/e399e166/attachment.pgp>
Re: [freenet-dev] Moving to Java 1.6???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, sorry for bumping an old topic, but I would like to know if there were any conclusions on moving to Java 1.6? If I followed the thread correctly, there were some problems with Mac OS X users. But Apple is working with Oracle now, to support Open JDK for Mac OS x. http://www.apple.com/pr/library/2010/11/12openjdk.html artur Am 28.10.2010 14:21, schrieb Matthew Toseland: > It would simplify the build process and enable us to use new language > features if we moved to Java 1.6. The problem is: > 1) Mac OS/X 10.4 only has Java 5. As I understand it you have to pay for > upgrades, and they are disruptive, so most people don't? > 2) It would slightly increase the difficulty of getting Freenet working on > free JVMs. > > Is it worth doing it anyway? How many people run OS/X 10.4 nowadays? > > > > ___ > Devl mailing list > Devl@freenetproject.org > http://freenetproject.org/cgi-bin/mailman/listinfo/devl -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNIF/gAAoJEMCbH/uYbXaWahAH/3aUtAhutXl5mbg9C9Mp5IC9 1XFhhvFOD3hS94WpNwjjLRysSViKjIrCG7y8FGSZpdCYEgagT3R+sk/I1jvnTkQg DVM2DOm8cryLBrCLEuf5iqDzwus89nLSLJQ6uTni5zBO+3cp5VMit6Q4vrp9co6w Dhfohh8ikv24MddDe9+6guM+q+0+e4YEwHJW6pLpgi1iyZ1NCfyhu4xAJdbt8JP6 gZYpMb8i7r8qrzBsHQkUCaqfQpVdAvQk2TuP0iXOsIO26U1uOGMZVQ1KUYmTSktQ RwREju32x/p3qWUmkGrVPyW8wQWhu7JXQYVBpuxUpVJOckx+9ufMid12L0eda90= =9END -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] [freenet-support] Freenet 0.7.5 build 1314 (and 1313)
Hi, I still have an exception here. It happens right after I entered my password: http://www.mxchange.org/downloads/freenet/array-index-out-of-bounds.txt After this I accessed http://127.0.0.1:/downloads/ but I still got a NPE: http://www.mxchange.org/downloads/freenet/npe1.txt Roland signature.asc Description: This is a digitally signed message part ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project
I apologise for replying before I at least had a proper look at the website! This is in fact fascinating and there may well be things we can do together or at least inspiration we can draw from one another. Lets get detailed, technical, and concise, about what would be involved in Freenet working with Unhosted, as one of many options for transport etc. Sorry for the general waffle last time, it's worth reading though. The basic principle of Unhosted from a freenet-ish angle is: - Websites are static and therefore can be hosted absolutely anywhere. - The website is a (large?) javascript applet. The client trusts the author of the website, within reason. - Data is encrypted by the client. - Data is stored on a separate storage server. - CORS allows this (this requires relevant request headers) - The PKI sounds very strange! On Freenet we always pass the hashes of the pubkeys... :| Now, compare to Freenet: - Freenet is reasonably good at hosting static content. - It strips out javascript in order to preserve security. This happens at the fproxy level; if the app is trusted it could be whitelisted or something. - Data is stored by clients for themselves, which is easy on Freenet, or it is routed between clients via queues, which is somewhat harder: Because of spam problems, we need to announce identities and establish a web of trust between them, or at least that's how current stuff works; we could use CAPTCHAs or some similar scarcity mechanism directly on a per message basis, but once a relationship is established it is unnecessary, and there are serious worries about the long term viability of CAPTCHAs. - Your PKI sounds rather strange... We could probably provide a WoT-based lookup service and be API-compatible though... There are some interesting sandboxing options. The big difficulty preventing Freenet from allowing Javascript is not the difficulty of writing a javascript filter (although that is a hard problem it is a solvable problem); it is the difficulty of defining a safe API for it to call. Freenet only provides request and insert - fetch and put - but with that alone, a malicious app author can do a lot of mischief. I wonder if we could build a usable sandbox based on Unhosted principles, i.e. an app can download and upload data specific to its user, and can talk to other users. We could even provide a confirmation mechanism per-user for more paranoid users, which could smoothly integrate into the app's UI if we are really good, including CAPTCHA-based introductions ... h, there could be something in this ... might need API changes though, how do you deal with introductions now? Such principles may be valuable to Freenet even if we have to break compatibility with Unhosted... Thoughts? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] [unhosted] Unhosted and Freenet Project
Following up Alex's possibly naive handwaving. Read at your leisure. On Friday 14 Jan 2011 13:19:55 Michiel de Jong wrote: > Hi! > > My name is Michiel, I originally founded Unhosted, about three months ago. > One important thing for you to understand about Unhosted is that there is > hardly any code (yet), and although there are a few proof-of-concept > applications that use unhosted technology, these are not real-world / live / > production websites. We hope to create and convert websites to unhosted > architectures during the course of 2011, but as yet this project has only > about 2 man-months of work done on it. So very early days. > > Also, I must warn that despite what many people seem to associate it with, > unhosted is a project that aims to break web2.0's monopolies by giving > open-source websites certain scalability techniques (so that they only have > to publish their source code and don't need to supply so much server power). > it is not at all about providing anonymity (nor to the publisher, nor to the > viewer) Right. Until and unless Freenet has overwhelming advantages in e.g. performance (which I once believed was possible, I dunno now, we'll see), most unrelated projects which don't have closely related goals will not want to associate with it. For much the same reason that the Wikimedia foundation is distancing itself from Wikileaks. Having said that some of the technologies may be common. HOWEVER, what Unhosted is mainly about according to Alex is applications. Freenet isn't interested in distributing applications. That is, our anonymity/security/privacy goals make distributing applications extremely difficult. Freenet is about data; apps are layered on top of the network, which provides get and put operations (and not much else). > > On Fri, Jan 14, 2011 at 12:43 PM, Alex Rollin wrote: > > > Hello, > > > > I have been looking through the site and wiki for Unhosted: > > http://www.unhosted.org/ > > https://github.com/michiel-unhosted/unhosted > > > > and comparing the desired decentralization goals with that of Freenet: > > http://freenetproject.org/ > > > > I wonder if these two projects are not links in the same chain for > > higher availability complex behavior in anonymous browsing and > > small-world networks? > > I'm sure there are things we can complement! Please explore these, and I'll > be happy to answer any questions you may have about what unhosted is > planning to do, and also to change course on things if that makes more sense > given what you are doing. You are the existing project, and we are the new > guys, so we are the ones who should refrain from reinventing the wheel if we > are investigating similar things. Cool, good to have an expression of mutual respect. > > As for the details of the rest of your post, I must admit I don't understand > it very well. I thought freenode was a way to make sure "no one knows you're > writing" instead of as you say "no one knows you're reading". or maybe it > automatically is both? We aim to provide anonymity for both. However in practice we provide only limited protection against a determined attacker, unless people use darknet (friend to friend connections). > > Can you elaborate a bit on the change that is happening in freenet towards > 'formatting the data'? Chat systems are inserting XML for various reasons. There are also distributed search mechanisms (fetching by keyword isn't always ideal for e.g. space reasons so we've implemented a yaml-based btree). > > What unhosted does is propose a list of per-user resource protocols, and a > list of discovery mechanisms for them. for now, we propose a simplistic > 'SET/GET' KeyValue protocol, and a simplistic 'SEND/RECEIVE' MessageQueues > protocol (so two modules so far). Discovery mechanisms so far we have only > one, which is WebFinger-based. Set/get key:value from the user, stored in a distributed fashion? And send/receive to a user from others? Freenet has somewhat similar things in some of the higher level apps, however it has to deal with anonymous spam, so the chat clients use a Web of Trust. > > Since unhosted is a focus on per-user resources, and freenet is a focus on > anonymized resources, maybe the two are even opposite in that sense if you > know what i mean. But they can coincide if we talk about 'per-nick > resources' instead of per-user, where the link between nick and physical > person stays secret. This immediately breaks down however if you would have > to identify yourself on a traditional website using your supposedly > anonymous nick. IMHO there is almost always an identity of some kind linked to resources, even if it is only a public key that was never used for anything else. For instance, in future Freenet will announce uploads via its chat system. Truly anonymous announcements are extremely difficult, given spam: It is far more efficient to create an identity and reuse it, gain trust for it etc. > > Unhosted is essentia
Re: [freenet-dev] Open Knowledge Foundation Distributed Storage Research Project
On Friday 14 Jan 2011 11:56:09 Alex Rollin wrote: > http://wiki.okfn.org/p/Distributed_Storage > > The group has chosen Tahoe for their grid, it appears. Does this help > with anything>? Here are their use cases: > > Use cases for Tahoe grid Academics generally dislike Freenet because not much is published since 2000 and it's generally too heuristic, not enough is provable, compared to classic DHTs. > > We get the same two features of backing up, and sychronising the new > stuff (not file diffs) to a different computer. > > case 1 > The whole repository of a particular type is all copied down into the > server. Tahoe is used as a backup and moving of the server's data. > Everything is available for processing across all of the data. The > server can add new files to the repository. > This case applies to undemocracy and parlparse because all the data is > needed in order to present users with statistical figures (eg > attendance rates in votes). > > case 2 > Files are served directly out of Tahoe through a server. The full > repository is not copied down. The server merely caches some files. > More useful for delivering the PDF documents or images where > statistical analysis are not always wanted. More broadly speaking, distributed backup and similar stuff generally needs reliability guarantees that Freenet can't provide. Also, look at their goals - performance is important, privacy is not. Until and unless Freenet shows that it is in fact possible to have really good performance while still having hard privacy, this is not an appropriate use case. One interesting factor is that we should have tools to probe data retrievability without having to bootstrap a new node, and to automatically maintain either your site or somebody else's. This is planned, or at least, there's a bug for it and it's been suggested many times. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Solving the release policy problem for 0.8.0
On Wednesday 02 Feb 2011 18:36:03 Bill Ritchie wrote: > I'm very overwhelmed in trying to put my 2 cents into this, but here it goes > > 1) We need to have a documented release strategy, even if it's loosely > documented. I've been working on some grant proposals, and many of them want > a timeline of goals. This timeline is very important. It's used in evaluating > if the project is worth the grant, as well as determining if the project has > reached the goals for which the grant was given. The problem is that in > order to have the timeline we need to have a good release strategy that says > here is our workflow. Here is how we get from where we are, to where we want > to be, and here is how we can evaluate the changes. This is key. I'm not > even talking about what goes in, and what stays out, and when we do a > release. We need to document HOW we do it and HOW we follow up. Without > this it's kind of hard to ask for money. The problem is the process is rather chaotic, goals can *legitimately* change over time, new problems are found on all levels, there are endless bugs. If we build a roadmap, we won't stick to it, because we discover we need to fix X Y and Z bugs, then we decide we need a release and the deadline is more important than the features we were going to put in. We are not building a word processor here. Some things can't be planned out fully in advance, although of course a lot of things are, and ideas can bounce around for years before reaching their final form. Some things are even somewhat research-driven or empirical. Some things we haven't even worked out the theory yet, such as the final form of the Pitch Black fix. > > 2) Freenet kind of looks like it is very unorganized. Again it's hard to ask > for things if we don't have our ducks in a row. If you look at some of the > more successful projects they have a clearly defined set of goals, timelines > to those goals, designated roles for key people, and a defined workflow. There are limits to how much of this we can realistically expect IMHO. We can set goals but they will be changed. This is what usually happens with Summer of Code projects, for instance, and they are supposed to be limited and self-contained. As regards roles, we need more people, although we try to encourage people to do what they are interested in. > All of which is listed in a public place somewhere. This disorganization is > limiting Freenet in other ways as well. Right now it's very hard to for new > users to contribute to the project, and I think that a lot of this is because > people are overwhelmed and get lost when they try. Freenet is a very > technical project and there are a lot of places it can break. I think that > if we were a bit better organized then we could direct new users to where > they would be most useful. There should be a set of clearly defined groups. > Each group should have a general set of guide lines, and responsibilities, > and how to contact the group. Examples would be a group in charge of > website(s), another in charge of donations and grants, the programming group, > Bug squishing group, the plugin group, documentation group, and a group that > oversees everything. There might already be something like this, but I just > don't see it. There would need to be a lot more people. > > 3) drop the release numbers, and go to a rolling release. It really doesn't > matter if it's version .75, .8, or even if it is 222. Those version #'s are > meaningless. Freenet is self bootstrapping. In other words after someone > downloads and installs the client, Freenet will normally update itself to the > latest version.Define the parts that need to be updated, and the order in > which they need to be done. In other words, something like we need to have > feature Z, but to do that we need feature Y, and that needs feature X. This > gives us our timeline for #1 above. And it also sets our progress level, > making it easy to see what needs doing and how fast we are doing it. I also > think that this might make things feel less pressured trying to get things > done for some arbitrary deadline. If some feature turns out to not be that > liner then even better. It also give the us something to update on the > website, as each feature is finished we can put a little blurb up. Gives > people something to look at and not think that Freenet is dead (because it's > not) We have roadmaps, AND we have deadlines. Ian insists that deadlines are more important. His reason for this as I understand it is to prevent feature creep, and to ensure we get a release in a timely manner. But the broader issue is what is the point of release numbers? We have a rolling release in practice. The purpose of release numbers is publicity, and the purpose of publicity is 1) money and 2) growth in users (leading to 3) more developers). > > Anyway I'm not done yet, but my fi
[freenet-dev] Call for seednodes and explanation of current problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.02.2011 01:43, schrieb Matthew Toseland: > On Friday 11 Feb 2011 21:39:34 Arne Babenhauserheide wrote: >> On Saturday 05 February 2011 18:39:49 Matthew Toseland wrote: >>> We need more seednodes. I will explain the broader situation below. If you >>> can run a seednode - which means you need a forwarded port, a reasonably >>> static IP address (or dyndns name), and a reasonable amount of bandwidth >>> (especially upstream), and a reasonably stable node, please send me your >>> opennet noderef (from the strangers page in advanced mode), and enable "Be >>> a seednode" in the advanced config. Thanks. >> >> How much upstream do I need exactly? >> >> I can offer about 50kB/s (damn asymmetric DSL?), dyndns is no problem. > > That's what I used to use when I was a seednode. It's a bit painful but it > works. My seednode is running with 64kB/s,.. so not much more. And it is not always using up its bandwidth. So I would say it should be sufficient. artur -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNVkVFAAoJEMCbH/uYbXaWzdoIAK/Ht2Pl1IqHeeA4KuH8jxMy 101YmTGJarlivGGe6P5uff2dW6tLEUXzVbqWPplWYNgCywnkjrFH96rPlr3UIm8C ODwzZspx5+NFQ0VSqbnC3kLo+tOnfJhXfvutEug+VtPNp5PJrdRmvbe47q4JtJhc uA5JqdgTtOlHo1/GG6QikYudl1cmnOFFGW/Xm2NYTjcE3tzGkD5AlAnapWCV9xlK f63pYBW/hx5aFf9AJE26uyOc/CiRIhF1mk09WzSW8z3BP9w8GVyr8V9PoeO+P6O5 AAKPTEKUmzJaP+i/x+XcoqFgGAT+1Vyur4MFlxkUk/UMDHYKBPXS3OQ551bEe98= =wygc -END PGP SIGNATURE-
Re: [freenet-dev] Solving the release policy problem for 0.8.0
On Monday 24 Jan 2011 23:44:44 Ian Clarke wrote: > On Mon, Jan 24, 2011 at 12:34 PM, David ‘Bombe’ Roden < > bo...@pterodactylus.net> wrote: > > > I have recently started using the branching model suggested by Vincent > > Driessen in http://nvie.com/posts/a-successful-git-branching-model/. At > > first > > the amount of branches that are created seem overwhelming but after a short > > time the benefits of having features cleanly separated before merging them > > outweigh the added complexity of the graph in gitk by far. > > > I'm all for doing things in ways that have been proven successful by others. > The current approach which involves a variety of independent repositories > does seem fairly peculiar. Independant repositories for each subproject is sensible and normal practice. Now, to examine the page above: It is interesting that he endorses a push-based model, where many devs have push rights. This mostly works but it is tricky when a big change gets pushed and then undone in review. Generally the view is that it's better to just have many repo's and pull requests. Although right now quite a lot of people still have push rights. Some devs openly prefer posting pull requests. New devs are generally encouraged to branch via github and post pull requests. This certainly makes life easier for me with the current release process. If we did choose to continue with a many-push model, we'd probably want to set some rules about what branches you can push to. He uses "master" for the stable release, and "develop" for the latest pushed stuff. We use master on the stable repository for the stable release, and "master" on staging for the latest pushed stuff. So far so similar. Having said that, lately we use release branches a lot, which can diverge quite a bit from master. Feature branches I use in origin for larger changes, and a few other people do. Devs who post pull requests almost universally use feature branches. Feature branches are good, IMHO better than developing directly on master in most cases. Arguably they should be used for even relatively small features. Using the --no-ff option when merging a feature branch is a good idea. Release branchs are a good idea. At the moment I use release branches whenever I need to release some small part of what is on master. Wider use may make sense. I only update the version number at the last minute, which IMHO is better for our use as things may happen that make the branch planned to be a release actually into the following release. These are often, but by no means always, actually hotfix branches by his model. And of course we use signed tags for all releases, and for prereleases too. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Freenet 0.7.5 build 1352
Freenet 0.7.5 build 1352 is now available, please upgrade, it will be mandatory on the 19th. This build significantly speeds up bulk transfers; we were only allowing one packet in flight at a time, now we allow up to 100 depending on various factors (provided that the peer we are talking to supports new packet format). Bulk transfers are used in friend-to-friend file transfers, but also in Update Over Mandatory (updating nodes that are so old that we can't connect to them as proper peers); slow and timing out transfers have been a problem recently; and it is also used in path folding and announcement (although for small transfers the gain won't be as much). Please upgrade! Thanks. Please report any problems you find. -- 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/20110212/bec51ad3/attachment.pgp>
[freenet-dev] Call for seednodes and explanation of current problems
On Friday 11 Feb 2011 21:39:34 Arne Babenhauserheide wrote: > On Saturday 05 February 2011 18:39:49 Matthew Toseland wrote: > > We need more seednodes. I will explain the broader situation below. If you > > can run a seednode - which means you need a forwarded port, a reasonably > > static IP address (or dyndns name), and a reasonable amount of bandwidth > > (especially upstream), and a reasonably stable node, please send me your > > opennet noderef (from the strangers page in advanced mode), and enable "Be > > a seednode" in the advanced config. Thanks. > > How much upstream do I need exactly? > > I can offer about 50kB/s (damn asymmetric DSL?), dyndns is no problem. That's what I used to use when I was a seednode. It's a bit painful but it works. > > Does that suffice? > > Best wishes, > Arne > -- > Ein W?rfel System - einfach saubere Regeln: > > - http://1w6.org > > -- 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/20110212/bb3cec79/attachment.pgp>
Re: [freenet-dev] Call for seednodes and explanation of current problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.02.2011 01:43, schrieb Matthew Toseland: > On Friday 11 Feb 2011 21:39:34 Arne Babenhauserheide wrote: >> On Saturday 05 February 2011 18:39:49 Matthew Toseland wrote: >>> We need more seednodes. I will explain the broader situation below. If you >>> can run a seednode - which means you need a forwarded port, a reasonably >>> static IP address (or dyndns name), and a reasonable amount of bandwidth >>> (especially upstream), and a reasonably stable node, please send me your >>> opennet noderef (from the strangers page in advanced mode), and enable "Be >>> a seednode" in the advanced config. Thanks. >> >> How much upstream do I need exactly? >> >> I can offer about 50kB/s (damn asymmetric DSL…), dyndns is no problem. > > That's what I used to use when I was a seednode. It's a bit painful but it > works. My seednode is running with 64kB/s,.. so not much more. And it is not always using up its bandwidth. So I would say it should be sufficient. artur -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNVkVFAAoJEMCbH/uYbXaWzdoIAK/Ht2Pl1IqHeeA4KuH8jxMy 101YmTGJarlivGGe6P5uff2dW6tLEUXzVbqWPplWYNgCywnkjrFH96rPlr3UIm8C ODwzZspx5+NFQ0VSqbnC3kLo+tOnfJhXfvutEug+VtPNp5PJrdRmvbe47q4JtJhc uA5JqdgTtOlHo1/GG6QikYudl1cmnOFFGW/Xm2NYTjcE3tzGkD5AlAnapWCV9xlK f63pYBW/hx5aFf9AJE26uyOc/CiRIhF1mk09WzSW8z3BP9w8GVyr8V9PoeO+P6O5 AAKPTEKUmzJaP+i/x+XcoqFgGAT+1Vyur4MFlxkUk/UMDHYKBPXS3OQ551bEe98= =wygc -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
