On Monday 17 August 2009 16:35:09 xor wrote: > On Monday 17 August 2009 16:33:53 Daniel Cheng wrote: > > Do you see the pattern? > > Many of the "bugs" are just enchancment/idea that come up on mail list / > > irc. Some of them don't even have an conclusion on wether we should > > implement them. And "we don't have to lost it" -- it is more like a ever > > growing todo list that no body care about. > > Feature suggestions are a "good thing (TM)". We just need to consequently > mark > all feature-suggestion issues as feature suggestions! > Having many of them is good: If a new volunteer asks us "hey, I'd like to > write a new feature for Freenet, what can I do?" then we can tell him to read > some random issues in the bugtracker until he finds one which sounds fun to > him.
Agreed. > > - People who want to contribute new code in general prefer to do stuff which > is > fun for them, and the more feature suggestions we have, the higher the > probability that a new developer can find something which he can enjoy. > > >> How about the real bug report? > > I don't see any real bug report from our "end user" in 20 bugs random > > sampling. > > Having a "report bug" feature in Freetalk will help us gather much more bug > reports from our users. Signing up to a bugtracker is very much work for most > people already and they just won't do it. > > - I'll definitely give some "report bug" feature to Freetalk as soon as the > more important features are done. Most notably private messaging. Freemail is not reliable, and implementing private messaging in Freetalk would allow integration with Freetalk - private replies to posts, for example. > > > If you filter out all the question/idea/enchancment and do the > > same sampling again. > > (which i will leave as an exercise for you -- as you have an hour a day), > > you will see most of them are : > > 1. duplicated of the ack'ed bug ( okay.. maybe this doesn't count) > > Yea does not count, duplicates must be closed consequently. Sure. > > > > > 2. variants of "network get slow recently" - kind of bug. > > without long-term network-wide performance data, we can't even > > evaluate the validity of > > this claim. let alone fixing it. > > Most of this claim are "network get slower after build #XXXX" > > We should close them as "unable to reproduce" as long as they only pop up > once > every few weeks and not every day. Right, they are intelligence, they are important if there are many of them or there is sufficient rigour that we can investigate in detail. > > And start writing an intelligent unit test which examines data reachability > after inserting and waiting for 1, 2, 3, N days? sdiz has done this but does not report data nor has managed to analyse it much. Such things are inherently extremely noisy, but I should run one in addition to my current daily fast push/pull tests (which you can access at http://amphibian.dyndns.org/freenet). I can do very basic analysis, but it's an incredibly noisy signal... > > > some of this "bugs" are just temporantory (a few days) because of > > node update/restarting. > > > > a variant of this is a "stort hit rate"/"success rate" drops > > after build release > > -- if you have ever care to plot a graph of that out, you > > know these rate > > would varies a lot just after node restarting. but we > > can't tell, because > > we don't have data. > > As I've said that is a sign for us that we need more unit tests and > statistical analysis tools. > > > I have tried to build a longer term monitoring -- (see the > > longterm*test class) > > Nice! =) > > > but i can't make sense of data -- mostly because my computer > > have restart often > > We probably need a dedicated machine solely for the purpose of online unit > tests. We might recycle emu for that. Too much bandwidth and anyway we want to *get rid of* emu so we don't have to maintain it or pay for it. > > > , don't have time to analyse the data, and the data fustruate > > from day to days. > > > > 3. db4o related glitches > > can't reproduce, can't fix. most of the time the reporter can't > > find a way to reproduce > > the bug (i don't blame him, because it is so hard) > > unless he is willing to go on irc and do an interactive session > > (with a developer), > > it don't have any hope get fixed. many of these report are > > even anonymous > > > > however, no one seems to have tried to close them as "can't > > reproduce". > > So we should *do* close them after some weeks/months as unable to reproduce. Or link them to a more general bug, such as the bug for backing up the db4o database. > > > 4. some simple typos / ui glitches > > if you have time, fix these, it would be more helpful then > > messing with the bug tracker. > > most of them are just one line of patch. but finding them out > > (from the bugtracker) > > take time. > > If I wasn't supposed to spend as much time as possible on Freetalk, I would > do > it. When I'm done with Freetalk, I will try to concentrate on spending more > time on fred itself. > > However, any of us volunteers should try to fix a few minor issues from time > to time. That's how open source works. I have been known to fix minor issues, but much of the time I am swamped with other things and don't use the bug tracker except to postpone stuff. But when I start working on an issue it can be helpful to have the record on the bug tracker. > > > Of cause there are some more types, but i have spend too much time on > > this email already. > > > > > and you only get 90 issues! That is manageable. > > > > 90 issues are too many, when you have a full time job and a real-life. > > Cutting down from 1300 to 90 just by setting a few reasonable filters is > impressive! > > And if one of the core developers would actually start working on them, that > number could probably be cut down to 40 or so within a few days. > > > a last hints/suggestiong > > https://bugs.freenetproject.org/view.php?id=3133 > > > > Nobody is monitoring this bug. > > Adding extra notes to this won't help. > > Your notes won't go anywhere. > > I don't know who has administrative rights in the bugtracker but it should > probably be assigned to that person. :) > > Yet adding a note pushes bugs up in the list and might get them some > attention > :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090817/3c9946e4/attachment.pgp>
