On Jan 18, 2008 1:50 PM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Friday 18 January 2008 18:07, you wrote: > Quality makes a releasable product, not time. If time is the most important > thing we should have a fixed semiannual or annual release cycle with date > based versions, as Gentoo for example does.
Its not black and white, but if you leave it years before an official release, then trunk becomes a de-facto release, with all the problems that this implies. Quality, time, new features, these three factors must be balanced. My contention is that we have allowed new features to completely override both quality and time, and this isn't acceptable. We should commit to a timeframe, I'm suggesting March 2008, commit to a reasonable quality, and then reduce the number of features until these commitments are reasonable. > But if we control the schedule > for maximum impact a major milestone release should be of reasonable quality: > opennet on its own isn't enough, we already had that in 0.5. Opennet isn't the new feature, darknet is! > So far we have 12. I hope this will be adequate and we won't have to do any > work on auto-harvesting, really I do (not least because of the need to learn > php!). You really won't have any trouble with PHP, its very simple. > > > [0] Ultra Lightweight Passive Requests. Essential for web of trust based > chat > > > applications, and generally useful. (2 weeks) > > > > No way is this essential for 0.7.0. > > I beg to differ. Sorry, my mistake, I didn't realized this was the feature discussed on IRC that Frost needs to avoid spam. > The point here is simply to have a way to publish content and especially blogs > *EASILY*. Having to load up Frontpage isn't easy, it's work. Nobody has their > own website any more: geeks sometimes use local blogging engines, and > everyone else uses big corporate blogging tools. That is all very well, but there is no reason to make it a precondition for 0.7.0. > > > [1] Tunnels. Michael Rogers and I have had some fruitful discussions about > > > security, it looks like some form of (optional) tunnels may greatly > improve > > > security at little code cost and some performance cost. (2 weeks) > > > > Why on earth is this a precondition for 0.7.0? > > Because the current code's security is rather poor, because *something* in > this region (not necessarily full blown tunnels) should be a relatively easy > improvement, and because we need to be able to honestly say 0.7 is an > improvement in security on 0.5. Now, superficially this is true because of > the diffie-hellman weak keys bug, although that has been fixed on 0.5 also > and was fixed in Tor two years ago; it's true because of darknet, but nobody > uses it; there are numerous minor improvements, but on the other hand, we do > a lot more requests for a file, and each request arguably gives away more > information than it did in 0.5 (hi to all you folk reading this on > slashdot/frost!). > > So if we can for example switch from HTL to a simple weighted coin (one of the > proposals under discussion), that would be easy to implement and might > improve security significantly. Full blown tunnels would definitely improve > security against a distant attacker, although they would likely take some > tuning to get right. Postponing full tunnels to 0.7.1 or whatever may be a > good idea, but if it turns out there is something *easy* we can do that goes > half way, we should do it. This is a slippery slope. We have already done a vast amount of work to take 0.7 beyond 0.5 - we simply can't try to implement every feature, whether security related or not, in 0.7.0 or it will never get released. We have to make some hard decisions and set a *very* high bar for the features we are going to try to get in 0.7.0. IMHO security nice-to-haves do not make this bar. > > > [1] Make big sites work well (multiple container inserts) (2 weeks) > > > > Same question. > > Content is king (after messaging!). Interesting sites are often big sites. Still nowhere near a good enough justification for it to be a precondition for 0.7.0. > > We do need to ensure that installation is easy and people can get from > > downloading to using Freenet as easily as possible. I would give this > > a [0] priority. > > Even on Linux? I'm happy to look into it; nextgens has done some work on it. Linux is maybe a lower priority, but a seamless installation on Windows and Mac are critical to adoption. > > None of this is a prerequisite for 0.7.0. > > Well, a Search Freenet! box would be a mind boggling feature for the typical > tried-freenet-years-ago-it-sucked user, that's all... and it wouldn't be a > lot of work. If it is 1 days work, then maybe - but not if it prevents a 0.7.0 release in March. > > > FPROXY: (1 week important, 3 weeks good-to-have) > > > [1] RSS filter. (important for blogging) (3 days) > > I listed this as Important because it's important to blogging. Blogging is 80% > of user generated content on the web now i.e. it's fairly important. OTOH if > we don't include a blogging engine the priority is greatly reduced. I get very concerned about this idea of bundling all sorts of apps with Freenet, we need to be a platform, not an entire distro. We shouldn't be forcing client apps on our users. > > > CLIENT LAYER / FCP LAYER: (3 days essential, 2w3d important, 4w1d > > > good-to-have) > > > [0] TestDDA working and mandatory for direct directory uploads. (3 days) > > I might drop this to [1] - I'd be willing to ship without it, but it does mean > we will have significant, backward incompatible changes to FCP later on. Ok. > > > [1] Much less disk space usage for uploads (various optimisations). (1 > week) > > I've done about half of this already. The second half may be harder though. > It's important but not essential. If it can be done and release 0.7.0 in March, then great, otherwise cut it. > > > DATASTORE: (1d important, 1w4d good-to-have) > > > [1] Datastore histogram. (1 day) > > IMHO this is important verification that we have a routing problem (the > datastore specialisation as measured by the stats code is nowhere near the > actual node location on most nodes). Ok, if its only 1 day. > > > CLIENTS: (~~ 1 week good-to-have) > > > [2] We should have some sort of client that supports uploading freesites > > > persistently. Bombe was going to fix jSite to do this. If not that, then > > > maybe a WebDAV plugin. (1 week for webdav plugin) > > Fproxy is now capable of inserting freesites, although admittedly it's not a > great interface. It will do well enough for the geeks/relatively dedicated > users uploading huge sites who have outgrown jSite in its current state. Ok. > What happens in March? Nothing in particular, but as we have seen over the years, if you don't set a deadline, then there is no incentive not to keep adding new prerequisites ad-infinitum, and you never get a release. You have to set a deadline to know when to start dropping features. March seems reasonable given that we've been working on 0.7.0 for 2 1/2 years. > Two months ago told me you had no principled objection > to doing some simulations of new load management algo's post opennet and pre > 0.7.0. I do have a principled objection to waiting another year, or even another 6 months for a 0.7.0 release. You can't do everything before 0.7.0 - there is life after 0.7.0. > I'm currently working towards alpha 2, which is mostly a matter of debugging > and some UI tidying. I hope to be in a position to release alpha 2 within a > couple of weeks at most - so lets call it February 1st for alpha 2. Maybe > even early next week if it goes well. What's the logistical plan? Alpha > justifies changing the web page, but not announcing to announce at fp, and not > actively soliciting a slashdot? If should definitely justify an announcement to announce at fp, but not slashdot. Ian. -- Email: ian.clarke at gmail.com Cell: +1 512 422 3588 AIM: ian.clarke at mac.com Skype: sanity
