I would just like to point out that I am not planning to meet the deadline of 31 January. The reasons for this are: 1. The critical features for the release - particularly new load management (which has recently incorporated new packet format) and darknet enhancements - really do matter. 2. In particular, I refuse to release without the darknet enhancements. Insubordination has its place, when you're right! And in this case I'm right. :) Having said that, the absolute minimum of darknet enhancements should be relatively small. 3. Equally, new load management matters. Right now the state of the network - even *before* the new packet format changes - is pretty poor. And IMHO new load management is long overdue - and most of it, believe it or not, is done already. However, several of the major components (notably new packet format and the timeout related changes scheduled next) will require significant debugging, and after the fact stabilisation. 4. The darknet enhancements were not envisaged when I agreed to the deadline originally. (My recollection is there was never a clear consensus for any particular date at a meeting, it was essentially an agreement between me and ian.) 5. Meeting the deadline will require avoiding debugging important bugs which affect users and prevent network growth. 6. Meeting the deadline will require not working effectively with volunteers whose interests are not directly aligned with the deadline: Postponing or more likely completely ignoring their work. 7. Making Freetalk work well will require significant work on debugging and improving USK subscriptions. It has recently become clear that this is developing into a serious crisis. 8. A public release the day after new load management is finished would be suicidal. Major changes at the network level result in the network performing badly for a while and need major debugging.
Basically, my point is that aiming for a feature complete but buggy alpha/beta will result in not addressing critical bugs, and that will make things extremely difficult for users, for unpaid volunteers, and will result in a very poor release, which will not go down well. And it won't be possible to meet the 31st jan no matter how much of a stressed out unhelpful anti-user anti-volunteer asshole I am in trying to meet it. IMHO what we need is: - A defined and limited set of features that must work reasonably well. - A tentative feature freeze. - A rough and somewhat flexible timescale. Clearly we *do* need a release in the fairly near future. There is an opportunity thanks to recent events. However, IMHO we are not yet at a point where we can set an arbitrary date and say we will release on that day regardless of stability and features. So I propose the following: - Any substantial feature not listed should be developed on a branch, and merged after the beta. In other words, a tentative feature freeze on master. However, contributions which enhance the code (particularly in bugfixes or stuff needed for plugins) without being too disruptive should be considered, for example yukam's work which I still haven't got around to looking at. - Volunteers can do whatever they want to, as always, but as mentioned above, anything substantial should be kept on a branch until after the beta. At which point only self-contained stuff will be considered; invasive changes will be post-0.8.0 unless there is a really good reason. - We are aiming for a beta. It should be feature complete and vaguely usable, but there is no urgency in fixing bugs which are not critical. However, bugs which affect end users in a big way in practice *should* be fixed. - Freetalk and the WoT *must* work. p0s is *really* close to releasing the new branch, after which Freetalk should be on the plugins page really soon. However, recently it has become clear that there is a serious problem with USK polling. This *must* work. This will involve significant debugging, but it may also require feature-level enhancements, such as enabling the client side code for date based hints. - New load management must work. New packet format appears to still have some serious issues, although some of the short term performance regressions are probably just due to network regressions. Some further debugging will be required. The next stage of new load management, which hopefully will be the final stage before getting back to debugging the core (which is actually coded and partially working although not 100% complete and certainly not fully debugged), involves the handling of timeouts, so it may be necessary to do some work debugging timeouts - which again overlaps with packet format work. We may run into other bear-traps, as with Freetalk, but we are getting there. - The basics for darknet enhancements must work. These are listed in a previous mail, are on the bug tracker, and are a subset of the ideas listed for 0.8.5. In particular, bugs #4624 (connect to FOAFs), 2604 (use FOAFs for connectivity), 4625 (route traffic to a subset of FOAFs to improve performance and avoid using opennet), 4629 (show FOAF names and allow to upgrade an FOAF to a friend possibly with an out of band verification password), 166 (invite mechanism, including the installer [1342, small debugging], and using friends for easy connection), 4630 (announce new FOAFs on the web interface) and possibly 4627 (recommend a newbie to friends when creating an invite), although it may overlap, and 3919 (minimal fix for the Pitch Black attack). The biggest task here is connecting to FOAFs, but none of these are huge, IMHO the whole lot could probably be done in two weeks. - The store-io and more-fortify-stuff branches should be merged. The first is potentially disruptive but seems to be working fine, but it should be given enough spacing to see whether it breaks anything. The second shouldn't be a big problem. Further fortify-related work can be postponed until after the release, it makes sense to deal with that in the beta-to-final stage. - I propose that we aim for a feature complete, usable but buggy release between *31 January* and *28 February*. This may slip but it should only slip due to critical bugs or one of the features mentioned above, and not for any other reason. -------------- 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/20110101/da9a05a2/attachment.pgp>
