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? > 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 :) > 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. > 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 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. 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? > 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. > 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 :) -------------- 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/f256f0e4/attachment.pgp>
