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. 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. 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. 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) 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-boun...@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.
