Rockbox mail archiveSubject: Re: RFC: Rockbox Flyspray policy
Re: RFC: Rockbox Flyspray policy
From: Martin Arver <martin.arver_at_gmail.com>
Date: Wed, 18 Oct 2006 00:28:16 +0200
Another issue with Flyspray at the moment is that it is not possible
to select an entire group of targets when you create your task. There
could be something wrong with the clickwheel on the Ipods for
instance. In that case you would want to file a bug report to Ipod,
not Ipod nano.
On 10/17/06, RaeNye <raenye_at_netvision.net.il> wrote:
> While we're at it, I suggest some changes to categories:
> - rename categories using a two-level hierarchy, e.g., "Plugins-general",
> "Plugins-video", "Plugins-games", "Env-building", "Env-simulator", "HW-LCD",
> "HW-remote", "HW-fm tuner", "Audio-general", "Audio-codecs", "UI-fonts",
> "UI-language", "OS-playlists", "OS-bootloader", "OS-ID3",
> - "operating system/drivers" and "drivers" should be united into
> - "user interface" should be split to "UI-button assignment" and
> - "settings" and "configuration" should be united
> - "HW-connectivity" should be added (suitable for all USB-related tasks as
> well as ipod accessories, etc.)
> And some little bits:
> - Which category is suitable for tasks related to file-system issues?
> - Is the "wps" category intended for themes or for code patches that change
> WPS functionality? Why not call it "UI-wps enhancement" or something like
> -----Original Message-----
> From: rockbox-dev-bounces_at_cool.haxx.se
> [mailto:rockbox-dev-bounces_at_cool.haxx.se] On Behalf Of Dominik Riebeling
> Sent: Tuesday, October 17, 2006 9:49 PM
> To: Rockbox development
> Subject: Re: RFC: Rockbox Flyspray policy
> 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 <rasher_at_rasher.dk> 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 (http://www.gimp.net/bugs/ 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.
> > ***************************
> > * ROCKBOX FLYSPRAY POLICY *
> > ***************************
> > FOR REPORTERS
> > =============
> 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 it.
> > 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
> - 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"]
> > SEVERITY LEVELS
> > ===============
> > * 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
> > FOR ADMINISTRATORS
> > ==================
> > 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.]
> > CLOSING REPORTS
> > ===============
> > 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-18