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.
>> 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
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.
How about the real bug report?
I don't see any real bug report from our "end user" in 20 bugs random sampling.
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)
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"
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.
I have tried to build a longer term monitoring -- (see the
longterm*test class)
but i can't make sense of data -- mostly because my computer
have restart often
, 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".
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.
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.
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.
>> > >
>> > > 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.
>
>> 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.
>
>> > - As you've experienced, all changes I am doing are being reported by
>> > mail to the other developers, so I am not doing anything hidden, it is
>> > publicly reviewed. So if you do not agree with any of my changes, feel
>> > free to revert them.
>>
>> I disagree with most of what has been done today
>
> That sentence is very useless for me if I want to improve my work. A detailed
> list of what's wrong would help.
>
>>
>> > - When setting milestones/target versions/priorities, of course that is a
>> > *suggestion* by me, and I only do it for issue where I am very certain
>> > about it. I want to help in getting an overview of what might be nice for
>> > 0.8.If you do not agree, please revert.
>>
>> The thing is, I don't have one hour a day to spend reverting your
>> modifications.
>
> Then delete the mails and let someone else do it. The whole point about open
> source community-driven projects is: Either you participate or you do not. If
> you do not participate then you must accept the fact that other's do your work
> and maybe do it worse than you could have done.
>
> You cannot demand that people stop working on certain stuff because you could
> do it better WHILE saying that you won't work on it (which you did by stating
> that you want the contents of the bugtracker deleted).
>
>>
>> > > Changing the priority of tickets you've no business with whatsoever
>> > > (you're neither a reporter, not a contributor to that part of the code,
>> > > nor even subscribed to the ticket) is just unacceptable.
>> >
>> > I am only changing the issues which seem easy to judge for a
>> > non-fred-core- developer.
>>
>> Take that one in particular: NAT-PMP support: It's reasonably easy to do
>> (I've implemented the up&p one: I know what I'm talking about), it would
>> improve the "reachability" of a significant number of nodes (all of those
>> behind Apple's routers at least). Connectivity of the nodes has proven, on
>> all p2p networks to be a key factor in efficiency (just read the literature
>> about it if common sense isn't enough) ... and yet you're judging it's
>> useless.
>
> I changed the priority to none because UPnP is the primary standard for port
> mapping in home-use-routers these days and apple routers are just a minority.
> Given the amount of currently active developers we do not have the time for
> supporting such small minorities.
>
> I've just changed it to "low" as a compromise, but I think that is okay
> because there is really much more important stuff to do (usability, stability,
> stability, stability etc. etc.)
>
>
>> > I consider this as very useful: People who have deep knowledge in
>> > how the node works should spend their time on doing stuff where that
>> > knowledge is *required* - it would suck very much if toad had to spend
>> > his time on resolving trivial issues which someone who has absolutely no
>> > knowledge of the node's internals (such as me) can resolve!
>>
>> So, if I'm following your logic, you've lowered the priority from "normal"
>> to "none", on the basis that it's not core stuffs and that toad shouldn't
>> work on it according to you.
>>
>> Is the only purpose of the bug tracker to be toad's glorified todo list? As
>> far as I know, he's grown up enough to maintain his own.
>
> The purpose of the bugtracker I'd say is to be the place where people who
> contribute code for the project on a *regular basis* and non-minor amount
> should manage their workload. The project right now does not seem to have very
> many regularly active developers and as we as programmers all know: We usually
> underestimate the amount of work which is in front of us, and that by factors
> like 2, 3 ... Therefore, it's better for the project if we mark stuff as low
> priority by accident than marking too much stuff as high priority and not
> getting the most important things done due to losing our focus
>
>> > Anyway, as you've been demanding to drop all contents of the bugtracker -
>> > I think it's better if a person who has "no business with whatsoever"
>> > cleans it up than just having all of the bugtracker be deleted.
>>
>> I don't. Starting from the grounds up would at least clear things up
>> "properly" and allow the project to define a policy on how to handle bug
>> reports.
>
> Losing well-defined information about HUNDREDS of definitely existing bugs is
> not proper cleanup. It's more like running away from the work which has to be
> done. It has nothing to do with professional development.
>
>> For instance, as I wrote before, users shoudln't be the one filling in bug
>> tickets on the bug tracker. For them we need another, simpler, possibly
>> anonymous tool.
>
> No, all we need is a special flag which marks the bug reports by users as non-
> reviewed so developers who want to do real work can just filter out the non-
> reviewed issues in their display.
>
> And that is status "new" vs status "acknowledged" / "confirmed". We just need
> to use it.
>
> And really that is the goal of my recent-tagging: Allowing proper filtering
> which ?only shows you HOT issues then.
>
> And it works: Set your filter to:
> - Status: Hide closed/resolved
> - Severity: major, crash, block
> - Priority: normal, high, urgent, immediate
>
> and you only get 90 issues! That is manageable.
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
