dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: RFC: Rockbox Flyspray policy

Re: RFC: Rockbox Flyspray policy

From: Dominik Riebeling <>
Date: Tue, 17 Oct 2006 21:48:50 +0200

It has been a while but I still want to post my thoughts. For easier
distinction I haven't trimmed the text but only added my extensions.
Comments are marked with square brackets.

On 9/30/06, Jonas H <> wrote:
> I suggest everyone pick this suggestion to bits, and when some sort of
> consensus is found, it should be put in the wiki and linked somewhere
> prominent on the Flyspray page.

I think we should divide this into subpages, similar to the bugs page
of the Gimp project ( which has already
mentioned on IRC some time ago).
I suggest having a UsingFlyspray (or rework ReportingBugs?) page which
is the only page that is linked from the side menu for all types. From
there we have separate pages for reporters and for developers.

> ***************************
> ***************************
> =============

Flyspray is *not* a support channel. Our support channels are the
mailing lists, the forums and IRC. For support questions don't go to
Flyspray as you'll get way better responses there -- the tracker is a
completely different thing and used in a completely different way. You
won't get any support from the tracker, it is used to keep track of
tasks *only*. Note that support questions in the tracker will get
closed without any comment!

It is *really* important that you follow the rules for our tracker: by
following these rules you make it easier for the devs to keep up with
bugs, feature requests and patches which in turn means you can expect
the development (and fixing of bugs) getting faster. Ignoring these
rules only adds extra work for the devs and wastes precious time that
could be used better for coding.

When signing up please make sure you provided a correct and *working*
mail address. Tasks you are involved with (as reporter or commenter)
get automatically notified to you when something changes. This is a
*really* important thing as it's useless to have a task which reporter
can't get reached anymore, especially on bug reports. Your mail
address won't get used for anything else than these notification.

> When submitting a task, please include as much information as you can
> think of. Be honest when you set the severity level, see explanation in
> the section below.

If you are unsure about a task you want to submit please ask in the
aforementioned support channels first. This helps saving work for the
devs and can also avoid you quite some amount of frustration.

A really annoying issue are duplicates. Please make sure the task you
are about to submit isn't already present. If there is a similar task
please take into consideration if it would be sufficient to comment on
that existing task. Again, if you are unsure feel free to ask in our
support channels. Duplicates require quite some work, and that work is
precious developer time. You'll agree that wasting deveoper time isn't
a good think, don't you?

> If you're submitting a bug, please explain:
> - What behavior you are seeing
> - What behavior you expected
> - How to reproduce the bug

Please make sure you can reproduce the bug -- if it's not reproducable
it's unlikely to get fixed. Also, make sure you have tried the latest
cvs build and reset your settings (see the FAQ pages on how to do
this). If you still can reproduce the bug it's worth filing. You may
want to ask on IRC before filing, maybe some dev is already working on

> If you're submitting a feature request, please include:
> - A detailed description of the feature you want added
> - If you want current behavior changed, an explanation of why your
> suggestion is better

Please also consider the following before filing a feature request:
- is the requested feature possible? Music players aren't PCs, so
there are quite some hardware limitations. If you are unsure please
ask in the support channels. You'll most probably get an answer
quicker and can help the tracker staying useable.
- is the requested feature compatible with the open source nature of
Rockbox? Rockbox is distributed as GPL which requires all work
included to be GPL. We can't add features that are incompatible,
regardless if it's from a source code point of view or any other.
- Don't file requests for new ports. They are completely pointless.
New ports will only happen if some dev is interested and owns the
actual device. Of course you are welcomed to start working on a new
port. See the NewPort wiki page if you are interested.

> If you're submitting a patch:
> - Explain in as much detail as possible what the patch does
> - Mention any related existing Flyspray tasks

- if your patch has issues that need to get adressed don't forget to
note them. Perhaps someone else is interested in your work and wants
to help you out.
- submitting a patch implies the assumption you want to get it
included into Rockbox. For that to happen your patch needs to work on
all players suppported by Rockbox (if it's specific to some series of
players make sure it doesn't break the other builds).

[Note: how to deal with patches the author doesn't intend to get
included? There is still a chance a user wants to share his work even
if he don't expects or implies it to get included. I propose adding a
new category for that, say, "snippets"]

> ===============
> * Bugs
> Critical - Potential damage to equipment or user (hearing, mostly),
> leaving Rockbox unbootable, all playback no longer working
> High - Core features (voice, individual codecs, menus, etc) no
> longer usable.
> Medium - Non-essential features (bookmarking) not usable. Core
> features periodically slightly broken.
> Low - Any bugs (except typos or cosmetic errors) in plugins.
> Non-essential features periodically or slightly broken.
> Very low - Typos, cosmetic errors
> * Patches
> If a patch fixes a bug or feature request, its severity level should
> match that of that task.
> Critical - Use only for fixing critical (as described above) bugs.
> High - Use only for fixing critical (as described above) bugs
> Medium - Adds or fixes a feature that will make Rockbox more usable to
> a majority of users
> Low - Adds or fixes a feature that will make Rockbox more usable to
> a minority of users
> Very low - Adds or fixes a feature that will make Rockbox most users
> will probably not notice
> * Feature requests
> Critical - Do not use
> High - Do not use
> Medium - The feature requested would make Rockbox more usable to a
> majority of users
> Low - The feature requested would make Rockbox more usable to a
> minority of users
> Very low - The feature requested would make Rockbox most users will
> probably not notice
> ==================
> When dealing with reporters, please be polite. We need reporters, and
> even if we don't care about an individual reporter, other potential
> reporters might be put off if we act rude towards a submitter. Even if
> he deserved it.
> Closing a report without giving a useful comment is not acceptable. The
> reporter should be told why his report got closed. For people following
> the tracker by email, not giving a useful comment can also be quite
> frustrating.

[closing a bug with the reason "fixed" and a patch with the reason
"accepted" should be sufficient though.]

> Use the related tasks feature if you see a task that is related to
> another. [should duplicates be marked as related? At least if the report
> has information not mentioned in the open report, that could be useful]

if there is a duplicate that has additional useful information one of
the two tasks should get closed but it also linked with the related
task feature. There is no reason having two open tasks for the same
issue as it only clutters Flyspray. Having the closed task linked
makes it only one click away for reference.

> [Should the status be used at all? If it should, it needs to be used
> more. As it stands, most tasks are unconfirmed, simply because no one
> edits it.]
> ===============
> This is a list of suggested comments for each close reason and should
> also serve as a description of when to use them.

[Do we really need suggested comments? Wouldn't it be better telling
the users how a closed task has to be understood if there isn't a
detailed reason attached? Repeating the same reasons again and again
is quite tedious and requires additional work]

> * Accepted
> Patches: Your patch has been included in Rockbox. Thank you for your
> contribution.
> * Duplicate
> Feature requests, Bugs: This report is a duplicate of FS#xxxx. In the
> future, please use the search feature to check if your issue has already
> been reported.
> * Fixed
> Feature requests, Bugs: The issue has been fixed in Rockbox CVS and will
> appear in the CVS build shortly as well as the next daily build.
> * Invalid
> Feature requests: This feature can not be added to Rockbox for technical
> reasons.

or this feature won't get implemented as we don't want it (for license
reasons, programming reasons, etc.)
[An example would be support for proprietary file formats. E.g. MS
Office is nothing a music player is intended for and nothing that is
feasible to support.]

> Bugs: This bug does not exist in Rockbox.
> * Later
> [I'm not entirely sure why you'd use this? At least not with the
> (relatively) small amount of tasks in Rockbox. I guess you could close
> it as "Later" and then search for closed tasks marked Later and reopen
> as appropriate, but I think that'd be overkill for this project.]
> * Out of date
> Patches: This patch is very outdated and isn't close to applying cleanly
> anymore. If you decide to work on this patch, either reopen this task or
> open a new task and mention this task in your comment.
> Bugs: This bug no longer exists in Rockbox.
> Feature requests: This or a similar feature has been included in Rockbox
> or the feature is no longer necessary/feasible.
> * Rejected
> Bugs: This bug does not exist in Rockbox
> * Remind
> [Same comment here as "Later".]
> * Won't fix
> Bugs: Your bug report details wanted and expected behavior. If you wish
> to have Rockbox' behavior changed, file a feature request and explain
> why you want the behavior changed.
> Patches: Your patch adds functionality that is not wanted in Rockbox.
> [You should always add a reason here]
> Feature requests: Your feature request has been rejected by the Rockbox
> developers. The feature or behavior you suggest is not wanted in
> Rockbox. [You should always add a reason here]
> * Works for me
> Bugs: I can't reproduce this bug. [Should only be used after asking
> reporter for clarification and still not being able to reproduce or if
> reporter doesn't respond.]
> Feature requests: The feature you suggested already exists in Rockbox.

 - Dominik
Received on 2006-10-17

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy