On Monday 17 August 2009 16:33:53 Daniel Cheng wrote:
> On Mon, Aug 17, 2009 at 9:16 PM, xor<xor at gmx.li> wrote:
> > On Sunday 16 August 2009 22:36:17 NextGen$ wrote:
> >> * xor <xor at gmx.li> [2009-08-16 17:33:15]:
> >> > On Sunday 16 August 2009 16:38:15 NextGen$ wrote:
> >> > > Hi,Being another developer who have __tried__ to fix the issue
> >> > > tracker,
>
> I think I have to say something here.
>
> On Mon, Aug 17, 2009 at 9:16 PM, xor<xor at gmx.li> wrote:
> > On Sunday 16 August 2009 22:36:17 NextGen$ wrote:
> >> * xor <xor at gmx.li> [2009-08-16 17:33:15]:
> >> > On Sunday 16 August 2009 16:38:15 NextGen$ wrote:
> >> > > Hi,
> >> > >
> >> > > What are you doing here? starting an edit-war on the bug tracker?
> >> > > Editing the priority/milestone of loads of tickets won't help to get
> >> > > them implemented... and it is spamming our inboxes (I'm still
> >> > > subscribed to most, like most of us).
> >> >
> >> > - People are complaining about the bug tracker being bloated and
> >> > unusable, therefore I'm trying to work 1hour+ every day on cleaning it
> >> > up. That is good, isn't it?
> >>
> >> I'm not so sure about that. Who's been complaining exactly?
> >
> > You for example.
>
> I think nextgen (and me too) think the current issue tracker is
> beyond fixable and should start from sketch.
Why? All which has to be done is properly tagging all 1300 issues non-
closed/resolved issues and marking issues as resolved which are not
resolvable.
This is a simple process on 1-by-1 base:
while(not all issues are tagged properly) {
review_issue();
decide_about_tags();
decide_whether_to_close_or_not();
continue_with_next_issue();
}
If you say "it's not fixable" then you say that there is at list one single
issue in the tracker for which you cannot decide what to do with it.
If we consider ourselves as UNABLE to decide for a single issue what to do
with it, then we must accept the fact that creating a new bug tracker won't
help: That single issue will appear in the new bugtracker again and then we
must consider the new bugtracker as not fixable again and start with a new one
again.
- Cmon, the only problem is that we are too lazy for cleaning the tracker up,
and creating a new one won't help because it will get messed up AGAIN after
some time and then we will have the same problem.
EITHER we learn to properly maintain our bugtracker or we have end up with a
screwed up bugtracker - no matter how often we delete all issues.
> >> Mostly people not using it. A bug tracking software is a tool intended
> >> to be used by developpers; One of the main problems we have is that we
> >> intend to make non-developpers use it by asking *users* to report bugs
> >> there.
> >
> > That's why we need to clean their reports up like it happens in zillions
> > of other open source projects.
>
> Freenet is unique in a way,
> To prove my points, let's do a random sampling of bugs
> -- bug 1000 to bug 1010 (for some older sample)
> 1000 reported by toad -- fproxy enchancment, no progress
It's a feature - I changed severity from "minor" to "feature".
That probably applies to many of the other issues below.
> 1001 reported by toad -- fproxy enchancment, no progress
> 1002 reported by toad -- installer enchancment, fixed by nextgen
> 1003 reported by toad -- fproxy enchancment -- related to 1000
> (not marked) -- no progress
> 1004 reported by toad -- fproxy enchancment, no progress
> 1005 reported by toad -- fproxy enchancment, (is this related to
> nextgen' student' gsoc?)
> 1006 reported by toad -- enchancment? -- should be a subtask/notes
> for 1004/1005,
> 1007 reported by toad -- network enchancment, fixed by nextgen
> 1008 reported by toad -- just a question, not even an enchancment
> [mark as assigned]
> 1009 reported by Jerome Flesch (the thaw guy) -- thaw bug(?) --
> resolved. 1010 reported by Jerome Flesch (the thaw guy) -- thaw bug(?) --
> resolved.
>
> bug 3300 - bug 3310 (for more recent sample)
> 3300 reported by toad -- interdex enchancment
> 3301 reported by other -- dup of the infamous "not acking" "bug"
> 3302 reported by Zero3 -- enchancment / todo -- depends on upstream
> 3303 reported by Zero3 -- enchancment / todo -- "feedback" (ugh?)
> 3304 reported by toad -- just a question
> 3305 reported by other -- dup of the infamous "not acking" "bug"
> 3306 reported by toad -- enchancment
> 3307 reported by p0s -- bug? it is by design.
> 3308 reported by p0s -- enchancment -- this simpily violate our
> security/privacy model, but no body notice as this is reported under
> [Freetalk]
> 3309 reported by p0s -- exact dup of 3308, doh!
> 3310 reported by Daniel -- a bug ... but i can't see how this can
> be fixed in near/medium future.
>
>
> 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.
- 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.
> 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.
>
> 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.
And start writing an intelligent unit test which examines data reachability
after inserting and waiting for 1, 2, 3, N days?
> 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.
> , 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.
>
> 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.
>
> 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: 197 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090817/f820b487/attachment.pgp>
