On Tuesday 19 October 2010 21:20:28 xor wrote: > Hi, > > I hereby wave my "AS A LONG TERM VOLUNTEER I AM SEVERELY PISSED OFF"-joker, > I really want this mail to get some attention: > > Some months ago I have reviewed over 500 issues (I guess its more like 1000, > I > stopped counting at 500) in the bugtracker to close as many as possible and > assign target versions to as many as possible. > > Now some current statistics from the bug tracker: > ============================================ > - Issues opened & resolved in the last N days: > 30 days: opened 24, resolved 2 > 60 days: opened 70, resolved 12 > 90 days: opened 99, resolved 18 > > - Total open issues: 1578 > > - Average open time of ALL resolved issues: 232 days !!!!!!!!!!!!!! > > - Issues with target version 0.8(-beta1) / on roadmap for 0.8: 411 > ============================================ > > And now have a look at the brand new "Roadmap" page in the wiki for 0.8: > http://new-wiki.freenetproject.org/Roadmap/0.8 > > Does this look like 400 issues? NO. > (To be honest it at least links to the roadmap page in the bugtracker which > shows the 400 issues. At the bottom....) > > And now guess which date is mentioned in the IRC meeting about the 0.8 > release? > NOVEMBER OR CHRISTMAS. It's IMPOSSIBLE to resolve 400 issues until then > So people are planning to release 0.8 while IGNORING what our developers and > users have flagged as important for 0.8 > Now PLEASE don't say again that most of the issues are NOT important - this > will only show that you are NOT properly using the bugtracker: IF you have > read most of them, then WHY did you not change the target versions? > > This is a SHAME. And it really PISSES ME OFF. > > I have continuously asked you to process them toad and you keep stating that > most of them are unimportant. IF they are unimportant then ASSIGN DIFFERENT > TARGET VERSIONS PLEASE, instead of just IGNORING the bugtracker for MONTHS - > which obviously is the fact if we consider the opened/resolved numbers for > the > past 90 days... > > This is NOT for the sake of satisfying me or annoying anyone, but for the > sake > of *professional* development: In a multi-(hundred?)-thousand lines of code > project, it is IMPOSSIBLE to manage what has to be done WITHOUT a LIST of > it. > And this LIST is the BUGTRACKER. And the list is being IGNORED for months. > > Also, do not forget that you are stepping on the feet of our users if the > average time of processing an issue is 230 days. > They don't report issues so we can ignore them. > > Because I know that this email will not have any effect probably I suggest we > change our policy for releasing new versions (version as in 0.7.5, 0.8, etc.) > to: > > ============================================ > 1. ALL issues with the given target version in the bugtracker must be > resolved, closed or assigned a different target version. NO release with a > single open issues in the roadmap page (= with the given target version). > 2. NO release if there are any issues with block/crash severity and no target > version. They must be assigned a target version first, which will cause rule > 1 > to hit maybe. > ============================================ > > I think as a software project which involves MONEY from DONATIONS we can all > agree that it is absolutely SANE to process all issues reported by our users > (= DONORS and VOLUNTEERS) before releasing new versions and it is INSANE in > terms of politeness and quality management that we keep releasing new > versions > for years without following the two rules which I just proposed. > > Also, the fact should be mentioned that most of our money comes from a > single, > large donor and I don't want to imagine what would happen if they looked at > our bugtracker so we should really clean the damn thing up while nobody has > noticed that we give a shit about bug reports. > > - I am damn serious when I say "INSANE", we are in the science & computer age > and yet we don't do proper project management at all. > We should try to behave like engineers and not like children who always just > run towards the next most colorful piece of candy. (Which we do, we > continuously keep implementing new stuff instead of fixing the old stuff > because > programming new stuff is fun) > > Greetings and sorry for being harsh - but I am running out of ideas how to > enforce bugtracker usage :( > - xor > 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) 2. It is true that some bugs get fixed and don't get marked as such on the bug tracker until much later. 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. 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. Especially as, thanks in no small part to Evan's efforts, we now have a fairly good grasp of most of these issues.
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. 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. :) 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. If you read the roadmap page you will see that the number of big features planned before 0.8.0 is actually quite limited: - Freetalk is essential, but mostly not my problem, and sits happily in its own repositories. - The Windows installer is essential, but ditto. - The new packet format and various filters, are all stuff to merge, and it's worth merging them ASAP to keep potential long term contributors happy as well as for their own sake as features/enhancements. - Easy UI improvements and easy optimisations are all limited catch-all categories relating to stuff that would be high value and low cost for the release, that a great many users care about, but that can be postponed if necessary. - IMHO fixing Library is a fairly important item, but it should be relatively straightforward. - The big network changes, including bulk vs realtime flag, were started opportunistically while the network was borked, and IMHO given how far these changes are already, given the serious brokenness of the current system, and given that we have funding, it is worth continuing with them. This was a major deviation from the release schedule in that we were filling in the last few mostly fairly easy gaps before a release...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
