From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Sat, 9 Oct 2010 14:40:59 +0200

On Sat, Oct 09, 2010 at 08:50:59PM +1100, Jonathan Gordon wrote:
> the replies there were about relatively harmless bugs which affect a
> very small proportion of users.

Maybe. Do we have real information on that? I think there have been two
issues (or classes of issues) mentioned in the thread:

r28000: unknown number of affected users I think, not harmless at all,
but if no fix is found in time, reverting a single commit on the release
branch will handle this.

Some skin issues (11591 has been talked about most): There seems to be a
lot of arguing about these bugs, but not that much information that will
actually help pin down the issue or even evaluate its seriousness.

I'll discuss some specific skin issues later on.

> There are far worse issues in the other 280 odd open bugs

Yes, very likely. In this mail I'll concentrate on UI bugs, but I'll do
a similar effort for all other bugs later today.

> Fact is there are 280+ open bugs, 13 of which are under the "themes"
> category.

I suspect some of the bugs in "user interface" may also be related to
the skin code.

> 3 are not really fixable (11039, 10686, 7006),

s/11039/10039/ ?

These three are also in at least three releases. Definitely not
regressions.

> 1 is charcell only (11592)

It does look pretty serious though. I don't think I'd be happy with no
progress bar. Any hints on where to look?

> 3 are actually *new* bugs (one of which was already
> closed as a non bug but reopened) from the massive rework which leaves
> 6 which could be considered regressions.

Personally I think that FS#11589 and FS#11592 look like we most want them
fixed before a release.

* FS#11589 because it's a crash bug in a reasonably common use case
* FS#11592 because (from my understanding of it) it seems to make a
           particularly important WPS feature not work

The other skin bugs I looked at (I ignored the very new ones that were
submitted around yesterday, and the ones from before, say, June) are
either things that are annoying for theme authors but not visible to
regular end users (tag X doesn't work when combined with Y), or are not
very visible in "normal" daily use.

FS#11591 is a bit of an edge case I think. As a user I wouldn't care
much about it, but trying new themes is something someone new to rockbox
is likely to do, and a new release is when we have most new users, so
this is the sort of issue that's very likely to be seen by new users,
and it's the sort of issue that makes things look unfinished, which may
well turn people away. This is made worse by the fact that it apparently
occurs on the clip, which seems to me to be one of the targets that will
bring lots of those new people.

So we need to find out how widespread it really is.

I wish I could find my clip to investigate...

> If you want a perfect release then everyone needs to chip in and close
> bugs, if you are serious about wanting a bug free release then some
> incentive is going to be needed. Realistically we will never get to 0
> open bugs (I'm looking forward to eating my words) and untill then
> having a hissy fit about minor bugs (where there is one person
> maintaining the code) isnt very clever.
>
> Lastly I'll remind the people that need reminding that everyone here
> is doing it as a hobby, when it doesnt become fun anymore people
> leave.

Very true.

> The only people who could be considered having any authority to activly
> force someone to work on something (or not work on something) is the
> RSB and the most likely outcome of that is burnt bridges and people
> leaving.

I (personally, I haven't talked about this with any other people) think
it's unlikely that the RSB would pronounce something more forceful than
"It's fine for release", or "We consider that the complaint that FS#XXXX
is a release blocker is correct". I don't think there would be a "Work
on this!" "order", or even "Don't work on this" (that's what a freeze is
for)

Also, the RSB is not bound to say publicly *who* complained, or even if
someone complained (of course if the complaint isn't rejected we'll have
to say something). Of course the complainant, the RSB members, and
(possibly) the person complained about would know, but I'm not convinced
that RSB invocation would necessarily lead to burnt bridges.

> So all that said, it is my opinion that everyone chill for a bit, we
> continue how we always have and release a mostly working release (with
> the only criteria being "better" than the previous), revert r28000 in
> the rel branch if that causes problems, and work to get the bug count
> down for 3.8.

I agree. In practise, I propose we look at the list of bugs (especially
those newer than 3.6, the others are by definition not a regression),
decide if there are some blockers in there, freeze, fix those blockers
(and other bugs if someone feels like it), and release.

As I said above, I'll go through the list later today and try to
identify further blockers.

Frank

>
> Jonathan

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Received on 2010-10-09