On Saturday 30 October 2010 15:42:33 xor wrote: > On Thursday 21 October 2010 08:33:52 pm Matthew Toseland wrote: > > > > To reply to the general issues, rather than point by point: > > 1. I repeat that most of the issues on the bug tracker are not critical > > blockers for the release that they are assigned to (and if they were they > > would be marked as such). If they can't be fixed in time for the build > > they are targeted to, then they can be fixed later. (This is ignoring the > > issue of invalid bugs) > > Well what do you say about my request to assign different target versions to > those of which you are the opinion that they HAVE a different target version?
Sounds like a good idea. However a lot of bugs are legitimately in the "it would be good if we could fix this before 0.8.0" category. I'll try to have another look at the bug tracker after I've dealt with my email backlog. > > > 2. It is true that some bugs get fixed and don't > > get marked as such on the bug tracker until much later. > > Ok at least we've established that :) And it's a bad thing. > > > 3. When we talk > > about November to January, we are talking about an alpha or beta release. > > We are not talking about the final 0.8.0, nor about a 0.8.0 release > > candidate. > > We all know that what will happen after the alpha is the following: > If it sorta works, it will be released as final. That has not been the pattern with previous releases. > > > 4. Even if we were, Freenet is still pre-1.0 for one very good > > reason: Freenet's security, performance and usability are all extremely > > poor compared to where they should be, while we have made enormous strides > > in some areas. These are the areas in which we need to concentrate our > > scarce and time limited resources, not in fixing every trivial bug that is > > reported. I would like to point out that quite a number of bugs are anything but trivial, e.g. in 1297 I fixed a nasty bug causing seednodes to fail to parse short packets from seed clients, resulting in them being bombarded with a lot of packets that they don't do anything with... Unfortunately the scarce resource on seednodes is usually *output* bandwidth... > > I have to repeat that my issue is NOT that you should FIX all but rather that > you should mark the issues which you intend to NOT fix with a different > target > version. IMHO this is legitimate however there are a lot of bugs that should not yet be postponed. > Not because I want to annoy you with that work but because the issues > need to be LOOKED AT if someone has considered them as important for 0.8 > You seem to constantly either misunderstand this point or ignore it, I hope > its clear now? It is a good point yes. Given the inevitable delays involved in testing each part of new load management before deploying it, there may even be some time available for it in the near future. > > > To elaborate a little, the 0.8 roadmap page on the wiki lists the *major > > features* that are essential prior to releasing 0.8.0. Bugs are dealt with > > separately: Once we have all the critical features, we release a > > feature-complete alpha (alphas are generally supposed to be largely > > feature complete), declare a feature freeze, and then fix as many of the > > bugs as we can in a reasonable, limited period, then we release > > 0.8.0-final. Some small feature issues may have a chance of slipping in > > after feature freeze - e.g. small tweaks to the UI - but no major feature > > work or big disruptive changes will be performed by me or allowed in the > > master branch (or release branch, if we decide to do it that way). > > > > That doesn't mean we don't debug in the meantime, of course, but it does > > mean that it is legitimate to be focused to some degree on the essential > > features. > > It is legitimate, but they should be reflected on the bugtracker roadmap page > aswell. This involves both having them as issues as well as assigning > different > target versions to non-major issues so people don't forget them. So you want me to assign all the bugs currently targeted for 0.8.0-pre1 to 0.8.0? I believe new load management is in the bug tracker... > > > An additional complicating factor is that as soon as Freetalk is ready Ian > > will declare a feature freeze and push for an alpha, whether or not the > > features I had hoped for are ready. :) > > Which will be rather soon I hope :) So its time to start managing the > 400-bugs > list of "minor" issues and checking which are NOT minor. This involves that > you read them actually. > > > Finally, it is absolutely not true that I never fix any bugs because > > implementing new stuff is more fun. Sometimes I implement new stuff rather > > than solving bugs because I have struggled with the bugs long enough, and > > have planned the rewrite long enough, that I'm fairly confident doing the > > long-planned rewrite is a more productive use of time. > > Ok well then I change my statement to: You rather do stuff which comes to > your > mind than reading the bugtracker and figuring out what the community has > reported as important :) > Except that the community doesn't use the bug tracker. :| -------------- 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/20101030/7e449726/attachment.pgp>
