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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110124/259b4e73/attachment.pgp>
