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 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>
